Thursday, March 15, 2018

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".

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 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 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.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog