Don Reinertsen approves (and corrects!):
Introduction
In
Principles of Product Development Flow: Second Generation Lean Product Development Don Reinertsen takes an economic/scientific approach to adapting lean approaches from manufacturing to product development, including but not limited to software development.
In doing so, Reinertsen provides the beginnings of a scientific basis to many of the empirical practices of Agile.
Interview (24 mins): http://www.youtube.com/watch?v=G-NbrISyfvM
Reinertsen says: "I believe that people in the Agile software space are doing a better job at using Lean in Product Development than companies that have forty years of experience with Lean Manufacturing, and that's because the Lean Manufacturing people have this toxic idea that variability is always bad and that it is feasible to eliminate variability. In highly repetitive manufacturing processes there's some truth to that, and in manufacturing processes you don't need to innovate. In Product Development you need to innovate in order to add value. As a result, if you try to drive out variability you drive out all of the innovation!"
Several of the principles that apply in Lean Manufacturing
- Minimise variability
- FIFO queues
- Waste as enemy #1
have to change when the context shifts to Product Development.
In terms of applying Lean continuous flow to Software product Development Reinertsen is inclined towards Kanban-based systems over Theory of Constraints-based systems. He recommends David J Anderson's book,
Kanban: Successful Evolutionary Change for your Technology Business for elucidation.
Reinertsen's book is quite dense: a 600 page book compressed into just under 300 pages. The density makes Don's summary talks worthwhile: he intends to write a 150 page version for non-Engineers "one day".
Summary of Reinertsen's talk to the Limited WIP society
Eight big ideas:
- Economics: use quantified models
- Queues: the invisible enemy in product development
- Variability: not the enemy: can profit from it (analogous to volatility in Financial Engineering)
- Batch size: reducing batch size is the #1 way to reduce queues
- WIP constraints: #2 way to reduce queues
- Cadence: offers additional performance opportunities
- Sequencing: additional gains available by prioritising Weighted Shortest Jobs First in queues (c.f. FIFO suffices in Manufacturing)
- Feedback: fast feedback loops enable better economic performance in the presence of uncertainty.
Big idea #1: Economics
"Provide product developers with good decision support information to make economic decisions."
- What you get: "An apolitical framework from which to make multivariate trade-offs". Enables effective decentralization of control.
- The alternative: "Get into ideological debates."
The #1 thing to quantify:
cost of delay (e.g. $ lost per month of delay of project delivery)
How accurate do you need cost of delay to be? Inter-rater reliability of individuals' intuition of cost-of-delay at the same organisation:
- Average: 50 : 1 spread
- Best: 10 : 1
- Worst: 200 : 1
"Any analysis beats intuition."
Implementation requires the construction of a quantitative model: in questioning Reinertsen said he can build this from the implicit P&L in a typical project business case, and that it's a lot less flaky than the ROI model, but he didn't give an example or recipe.
Big idea #2: Queues
"Invisible, unmanaged queues are the root cause of poor economic performance in Product Development."
Managing the invisible: make physical artifacts: e.g. Kanban boards, Scrum boards.
Why queues matter: queues
- increase cycle time
- lower quality
- increase variability
- increase risk
- raise overhead
- lower motivation
Just like a freeway at peak hour, running close to capacity blows out queues:
Clearly, minimising excess capacity drives costs way up. To minimise total cost, the cost of delay needs to be explicitly known:
Incidentally, these U-shaped optimisations crop up a lot in Lean Product Development.
Big idea #3: Variability ain't all bad
There's upside, too. C.f. Financial modelling: volatility implies opportunity (positive risk), as well as downside (negative risk).
This is different from manufacturing, where variability is all bad.
Big idea #4: Reduce batch size
"Halving batch sizes halves queues and halves cycle time."
Pros:
- Easy and cheap to implement
- Easy to reverse if there are problems
Big idea #5: Reduce cycle time by limiting WIP
"Reduce cycle time by limiting WIP"
Little's formula: Average cycle time = average WIP / average departure rate
Visual control systems (e.g. Kanban boards) help. These, with cumulative flow diagrams, show queues in a way that Gantt charts don't.
At the project level, serializing projects (rather than running many in parallel) means that:
- early projects are finished faster, delivering value sooner
- deferred projects can benefit from: more time for requirements to mature; learnings from earlier, completed projects
Big idea #6: Cadence
"A synchronised cadence offers additional performance advantages."
Cadence:
- makes maximum wait times predictable
- reduces coordination costs
- enables smaller batch sizes
Replace asynchronous processes with synchronous processes.
Big idea #7: Flexible sequencing
"Proper sequencing offers additional gains."
C.f. Hospital emergency room: expedite the person having a heart attack!
In continuous flow, prioritising according to weighted shortest job first (WSJF = Cost of Delay / Time) can result in gains of up to 96%:
A qualitative approach to WSJF for the Scaled Agile Framework
Big idea #8: Feedback
"Fast feedback loops enable better economic performance in the presence of uncertainty."
"Optimum failure rate in product development is frequently 50% (500k ppm); in 6 sigma manufacturing 0.00034% (3.4 ppm)."
Example: Hospital waiting room
- Two patients enter with chest pains
- Heartburn or heart attack?
- What to do?
- Buy information cheaply: find out if it's a heart attack (differential diagnosis / tests)
- Stabilise the patient, then treat at leisure: this lowers the Cost of Delay. C.f. Give the customer the most valuable feature(s) first, then take your time with refinements.
