Monday, February 18, 2019

Agile and R/D



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".(*)

"Completion" is problematic -- if not impractical -- in the R/D domain: completion implies a reasonable knowledge of scope;  heavy "R" implies a very limited idea of the means to accomplish an end goal; "D" is the flip of that.

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.

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 practices 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 practices that are "OUT"
  • Definite narrative of what's to be accomplished (Nylon, as an example, 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.


(*) 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.



Buy them at any online book retailer!

No comments:

Post a Comment