Thoughts on Principles of Product Development Flow, Part 2

This is the second in a series of a generally unedited “stream of consciousness” posts I am writing while reading Donald Reinertsen’s The Principles of Product Development Flow: Second Generation Lean Product Development. I haven’t been this affected by a book in a while, and I wanted to share my excitement with the world and test some of the ideas it is provoking. As such, this is intended to be an invitation to discussion, and I hope you will add your comments and disagreements below. If you wish to engage me in a detailed conversation, please feel free to contact me.

Motivations for Altering Software Development Processes

What you need to do is Scrum. It will shorten your cycle times and make your software better. No, what you need is Kanban and to flow value through your system at a steady pace. Bah, neither of those will work, what you really need is XP otherwise your software will be crap anyways, and you’ll drown in technical debt. No no no! What you really need is <insert flavor of the week here>.



Begin at the beginning.

We live in a world so saturated with jargon, catch phrases, and overly optimistic evangelicals of this methodology or that methodology-masquerading-as-a-framework that it becomes quite easy to lose the forest for the trees.

You should never be changing your software development process just for the sake of changing it. There is a reason, and this reason needs to be made clear well before any change is adopted. In most cases this is going to be as simple as increasing profits (I recognize that this may not always be the case for some public sector or business facing applications).

Shortened cycle time, eliminating waste, limiting WIP, driving feedback, increasing unit test code coverage and all the others are only proxy variables for whatever that root motivation actually is. This is not inherently a bad thing. These proxy variables are often much easier to measure and track and can provide great insight into your management process. The problem arises when we forget that these are proxies and start to optimize them for their own sake.

This has a few immediate negative externalities. Probably the most important of which is that none of these variables are completely independent. Reducing cycle time comes with a cost, and if we forget that cost (or ignore it completely) we may be making horribly wrong decisions in the name of optimization. The perfect example is utilization. We often like to forget that increasing utilization comes with very distinct, non-linear costs in lead time, morale, and code quality. Instead we treat utilization as if it were a completely independent variable that we can maximize without negative external effect.

I am not espousing rejecting these proxy variables, however I do completely agree with D. Reinertsen when he claims that the problem is one of different units of measurement. Each of these proxy variables are expressed in their own particular units, making an apples-to-apples comparison impossible. What we need to do is return to the beginning, uncover the reason we are attempting to alter our process and express our proxy variables in terms of that underlying motivation. 

D. Reinertsen chooses Cost of Delay as his metric, and I believe this is a good choice in nearly all cases. I could quibble that the metric is probably not linear, i.e. the cost of delay for the 1st week over time is more than likely not the same as the cost of the 12th week. However, I am 100% convinced it is better than no core metric whatsoever.

Problem: We can reduce the number of production bugs by 10% if we delay delivery by 2 weeks. Should we do this?

Answer: If you don’t know how to translate both variables into terms of Cost of Delay, you’re probably just making your best guess. But hey, you’ve got a 50/50 shot right?!


About the Author:


  1. Laura Lamborn February 21, 2013 at 9:40 am

    Great article, Andrew!

  2. Steven Borg February 21, 2013 at 1:56 pm

    But isn’t Cost of Delay just another proxy variable for the desired economics? In other words, Cost of Delay, like cycle time, isn’t a direct correlation to the $$ I get from delivery. Well, that’s not quite true. It is related to economics (money, or otherwise), but also includes a time metric. So you have a $$ over time metric. Why not $$ over quality, or $$ over scope?

    I suspect that, in product development (such as software), the ROI is still so high, that shipping faster is much more important, potentially, than other metrics.

    These are just a few quick thoughts. I loved the economics chapter of “Flow”, and he persuaded me that Cost of Delay (CoD) truly is the most effective way to measure economics. But your post made me question that, at least for bit.

    One advantage you have for CoD is that is potentially FAR easier to measure than most other metrics. You can simply ask the folks in sales, in some cases. And if you’re wrong, it’s likely not so bad to be a ways off. (It’s a U shaped value function… for a later discussion.)

    I really like what Reinertsen says when he speaks about asking teams to write down the CoD for their product. In a single team, it’s not uncommon for the largest CoD to be 50-100 times the size of the smallest CoD. If you do ANY work to quantitatively define your CoD, you’ll be more accurate than picking a random member of the team, and can actually use CoD to make decisions.

  3. Andrew Clear February 21, 2013 at 3:48 pm

    Cost of Delay is just another proxy variable. However the importance is that it is expressed as money/time which is easily understood be people outside of the software industry, and it is possible to express the other proxy variables in terms of cost of delay. This enables comparisons between two seemingly incomparable entities. We’re using cost of delay as a rough estimate to the proxy variable basis vector which would map our proxy variable space onto the economic space. (footnote at end of chapter 1)

Leave A Comment