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?!