Agile and R/D

---

I was recently asked if Agile and 'R/D' go together.

Good question! I'm glad you asked.

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?

Let's start with OPM ... Other people's money ... And the first question:
What have you committed to do with the money?
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: -- example: got a completion cure for cancer?

"Completion" means more than just effort; it has elements of accomplishment and obtained objectives. You can calculate an ROI applying OPM to "completion"

"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. Scope is assumed well enough known so that the price can be "firm" and "fixed".

Poor scope definition? Then, ask for "best effort".
The best example of "best effort" is "Time and Materials" -- T/M. If you're working T/M your obligation -- legally at least -- is best effort, though you may feel some higher calling for completion.

And, of course, ROI is problematic with T/M. The money may, or may not, develop anything with a dollarized business return.

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)

And, among the agile practises that are "OUT"

• 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"?)

There may be a longer list of "OUT"s, but to my mind there's no real challenge to being agile and doing R/D.

---

Buy them at any online book retailer!