Embracing Variability
It’s an all too familiar scene. The development team is asked to give estimates on how long they think the work will take. They know they’ll be held to whatever figure they give, and so to protect themselves, they give an estimate, with a buffer added in.
A Project Manager receives this information and committed to ensuring that his projects are always on time, decides to add multiple buffers to the dates provided by the developers as a safety margin. The project manager may think this is a win when the estimates are accepted. He believes he has greatly reduced uncertainty in the schedule by committing to a schedule he is now 80% confident about.
But, what is the cost of these buffers? The project manager is actually trading cycle time for variability.
The situation described above is familiar because in the current orthodoxy success is measured by how closely teams can conform to a plan.
A Broken Orthodoxy
This is based on beliefs and assumptions that have not been shown to improve process efficiency, which has led to confirmation bias. Reinertsen(2016) challenges these beliefs and encourages us to re-evaluate how product development work is traditionally managed.
Hostility to Variability
If you have ever found yourself in a situation similar to the example above, then, you know, the assumption made by product development teams is variability is bad. If we start from this point, then it makes sense to try to eliminate this variability as much as possible and to conform as closely to the plan as possible. John Cutler writes on Certainty Theatre, the pattern of rewarding certainty in organisations. Yes, there are certain situations where reduced uncertainty is a good thing, even the expected thing, however software development is not one of them.
Innovation
This hostility to variability and its trickle down effects are especially pronounced when considering how innovation happens. Teams operating at high levels of utilisation, with no slack time and a rigid plan they’re expected to conform to, have very little room to innovate.
Suppose work has started, and during design research more information that would add value to the product is uncovered. This, of course, would necessitate a change to the original plan, introducing variability and uncertainty. Eliminating all variability, would also eliminate the value added by introducing changes when more information is available.
If the focus is on delivery, and delivery in conformance to a plan, then success is measured as conformance to the original plan as much as possible, regardless of whether value is added or not.
It is important therefore to pay attention to variability, and the pay-off as a result of introducing variability and not conforming to the original plan.
A better way
Uncle Bob Martin’s advice in this tweet is a great place to start. Organisations may require heavy up-front planning which you may have no control over, however, making it clear that the dates and plans are at best guesses of how the next 6 months will look like is prudent, and the level of confidence you have in those plans. As the noise reduces and more information becomes available you can regularly update your plans.
Additionally, for as much as is possible, it is best to avoid heavy front-loading of detailed solution specification planning processes during the fuzzy front end, which is described as the messy “getting started” period of new product engineering development processes.
As I mentioned above, yes, there are some situations where eliminating all variability is beneficial, however, you may find, with a little inspection that there are multiple advantages to “respond to change, over conformance to a plan”
Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 7). Celeritas Publishing. Kindle Edition.
