Principles of Product Development Flow is a technical compendium of the principles behind Kanban and Lean. It explores the space where manufacturing analogies break down when applying Kanban to product development.
The book is often light on full implementation examples, leaving the reader to pick and choose what to apply. Overall though, it's worth reading, particularly on a chapter by chapter basis.
Here are the big concepts I took away:
Cost of Delay
The author prefers this metric above all others for prioritization decisions, but despite it's value, only a small percentage of companies he's worked with measure it. In short, Cost of Delay is the (risk adjusted) money you're leaving on the table by not having a feature or product in market.
It factors time sensitivity into decision making and provides a common economic basis for decisions. Trades between design cost and operational cost become much clearer when cost of delay is known, as well as choices between local and global optimums, and short vs long term gains.
Distributed Control through Constraints
An organization becomes more agile and responsive when individual members have autonomy to make their own decisions. The flip side of that coin is that it can lead to chaos and teams working at cross purposes.
By providing clear constraints and a decision making framework, those autonomous choices can be made in a distributed, yet organized fashion. The example in the book was a weight and part cost budget for a Boeing airplane. The initial budgets were a best guess and almost certainly wrong, but teams were empowered to trade one pound of weight for $500 of part cost. This allowed hundreds of teams freedom to adjust their budgets and seize opportunities without a centralized change approval process.
Work Modeled as a Markov Process / Work In Progress Limits
This section is for the math nerds out there. Queueing theory would describe product development tasks as Markov/Markov processes, which means that work requests arrive at random rates and processing time is also random.
Analysis shows that for a resource operating at 70% capacity, (which means there is an empty queue 30% of the time) there will still be, on average, a queue and a wait time before starting a job. As the average utilization approaches 100%, the wait time increases non-linearly and without bound!
Counter-intuitively, reducing utilization of individual work centers leads to globally faster processing times. Is a faster time to market more valuable that paying workers to do nothing? Cost of delay would tell you.
As an aside, the author also points out that increasing capacity (i.e. doubling the size of a cafeteria) is often an expensive proposition, but cutting batch size or limiting Work in Progress (splitting into two or three lunch shifts), is often cheap.
Thoughts on applying this to Hardware Engineering
The author provide an example for hardware, where teams typically review designs or drawings in one last step before ordering them. This is a clear case of a large batch that will lead to a long work queue in the procurement department.
The fix is to place Work in Progress limits on the number of parts or drawings that can be in design or review. The author also suggest that knowing parts will be released in small batches forces engineers to design interfaces and features intentionally so that they can be released early, before other features of the design are known.
I would love to try this idea, but in my experience, tightly packaged mechanical designs are too interlinked to decouple that way. I also point out that even when cost of delay is known, the operational cost of reworking hardware is orders of magnitude higher than fixing bugs in software, so holding parts for a review may be worth it.
Final thoughts
If you haven't read Lean MVP, I'd recommend that first over Product Development Flow as it's more digestable. If you're interested in applying Kanban to non-software processes, or getting into more technical detail of why Kanban works, then I recommend picking up a copy
Can you point me to the “Lean MVP” book? Searches don’t seem to be turning up anything.