I was recently asked if Agile and "R/D" go together. The issue at hand: how do you reconcile agile's call for product delivery to users every few weeks with the unknowns and false starts in a real R/D project?
Good question! I'm glad you asked.
Let's start with OPM ... Other people's money ... And the first question: What have you committed to do? There are two possible answers: (1) apply your best efforts; or (2) work to "completion".
Of course, (1) may be embodied in (2) -- why wouldn't you always apply your best efforts? -- but in the R/D domain (2) is often not a requirement and may be a bridge too far: -- got a completion cure for cancer? "Completion" means more than just effort; it has elements of accomplishment and obtained objectives.
"Completion" is problematic in the R/D domain: completion implies a reasonable knowledge of scope, and that may be impractical depending on the balance of the "R" with the "D". Heavy "R" implies very limited idea of the means to accomplish; "D" is the flip of that.
Of course, (1) may be embodied in (2) -- why wouldn't you always apply your best efforts? -- but in the R/D domain (2) is often not a requirement and may be a bridge too far: -- got a completion cure for cancer? "Completion" means more than just effort; it has elements of accomplishment and obtained objectives.
"Completion" is problematic in the R/D domain: completion implies a reasonable knowledge of scope, and that may be impractical depending on the balance of the "R" with the "D". Heavy "R" implies very limited idea of the means to accomplish; "D" is the flip of that.
The most constraining example of "completion" is Firm Fixed Price -- whether by contract or just project charter. FFP is almost never -- dare I say never? -- appropriate for R/D
And so now let's layer on Agile ... what's in and what's out vis a vis R/D:
Among the agile practises that are "IN" (in no particular order)
- Conversational requirements ("I want to cure cancer")
- Prototypes, models, and analysis (even, gasp! Statistics and calculus, though some would argue that no such ever occurs in an agile project)
- Periodic reflection and review of lessons learned
- Small teams working on partitioned scope
- Trust and collaboration within the team
- Skills redundancy
- Local autonomy
- Persistent teams, recruited to the cause
- PM leadership to knock down barriers (servant leadership model)
- Lean bureaucracy
- Emphasis on test and verification
- Constant refactoring
- Frequent CI (integration and regression verification with prior results)
- Definite narrative of what's to be accomplished (Nylon was an accident)
- Product architecture
- Commitment to useful product every period
- Intimate involvement of the user/customer (who even knows who they might be when it is all "DONE"?)
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog
