“Blindness to queues” is one of the cardinal sins of product development. Why? Well, here is a typical value stream map for a feature being delivered by a software team. Notice all the waiting?
Not laziness: lots of Work-In-Process; Demand > Supply
The reason for all the waiting is not that anyone is sitting around staring out the window or twiddling their thumbs. The picture above is from the perspective of only one of the potential things that is being worked on. In fact, the people needed to do these things are often overloaded. Because of our worship of efficiency, they are busy working on other things that (somehow) got into that part of the process first.
The other driving factor here is that demand outstrips supply. We have an infinite number of things we could do – I’m yet to see an organisation that has run out of ideas for improving it’s products and services. On the other hand, the “supply”, or capacity to develop those ideas, is highly constrained. No amount of increasing the budget or taking on venture capital can solve this. We have to choose.
Hidden Queues and Process Cycle Efficiency
The mismatch of supply and demand (not to mention the variability in it’s size, shape and arrival timing) means that, even with the best will in the world, queues will quickly form. The most invisible queues are those upstream of development.
You may think that your organisation doesn’t suffer from these hidden queues and long waiting times. Don’t take my word for it: take a random sample of a handful of features that made it into production recently. If you track the elapsed time and time spent waiting in your organisation you will almost certainly find something that looks similar. If your Process Cycle Efficiency (time spent doing value-adding work vs total elapsed time (including time spent waiting) is greater than 20%, then I would be very surprised.
Make the problem visible!
Organisations who have adopted some form of kanban (translation: “visual cue”) tend to have better visibility of their queues. Improving visibility is a “necessary but not sufficient” first step to understanding the cost of queues. For instance, it is a much easier argument to make that shrinking the last mile from “development done” to “ready for production” is needed if you can see it.
Thanks to fairly recent technical improvements, Continuous Delivery is now not only possible, it has become a widely accepted “best practice”. By largely eliminating these downstream queues, everything that makes it into the development pipeline takes advantage of the systemic improvements that have shortened and streamlined the pipeline. It’s a no brainer. How much you should be prepared to invest to make Continuous Delivery a reality though does depend on the Cost of Delay of the things in those queues.
Upstream is where it gets fuzzy
How far upstream this visibility extends varies greatly, however. As you can see from the one above, 32 of the total 46 weeks were upstream of the development team. This upstream, or “fuzzy front end” is typically less visible and largely uncontrolled.
Most organisations (even ones that are using a kanban system) are still immature in their understanding of the cost of queues further upstream. The tendency is to redraw the boundaries of the system and push this messy part off the page (out of sight out of mind), and focus on the flow efficiency and speed of the downstream part. The queues and waiting and the delay cost incurred upstream are effectively hidden – or at least someone else’s problem.
Understanding the economics of queues
Queues in Product Development are not inherently “evil”. To the great relief of the British public, we cannot say that queues are morally wrong. Indeed, some queues fulfil an economically useful function by acting as buffers, absorbing some of the variability in the system, improving the flow of work. As such, we cannot simply say that all queues are bad. The key to well-managed queues is not just visibility, but understanding the cost of those queues. The cost of a queue is the sum of the Cost of Delay of all the things that are waiting and how long each of those waits.
Categorisation by Urgency is not enough.
Some attempts at Cost of Delay ignore the value part of it. I guess this is because Urgency seems much easier to generalise and categorise. Yes, there are some useful patterns in how the urgency part works, but you can’t just categorise into a set of urgency archetypes and call it Cost of Delay. Considering Urgency alone only gets you half way there. Any “Cost of Delay” that fails to consider the value part of the equation is not Cost of Delay at all.
CoDiNO: Cost of Delay in Name Only.
And it’s close cousin…
WNSJF: Weighted by Nonsense Shortest Job First.— Joshua J. Arnold (@joshuajames) May 21, 2016
//platform.twitter.com/widgets.js
Where this approach comes unstuck is the fact that there are lots of things for which Urgency is very high, but for which the Value is negligible. Just because the best-before date of a perishable food is fast approaching doesn’t mean that we necessarily should drop everything else and eat it. The headlines of newspapers and clickbait articles on the internet are often time-critical, but with negligible value. The cries of a toddler in a toy store. Responding to emails, and other messages. Answering the phone. Buy in the next 30 minutes and get a free set of steak knives!!!
Conversely, there are also lots of things where the value is very high, but the urgency is relatively low. Often we can delay these things with minimal cost while we focus on other things where the rate at which value is leaking away is higher, even though to total value is lower. It is easy to conflate and confuse Urgency and Value. Part of the challenge in understanding Cost of Delay is to recognise that value and urgency are actually separate parameters, both of which are required.
Distribution matters
Every time I have seen Cost of Delay in the wild, when you look across the portfolio, project or backlog for a team, the distribution actually looks like this – a Power Law Curve:
Of course, you’ll only see this if you combine Urgency with Value and quantify the Cost of Delay. This is not intuitive! It is not what most people expect. It feels wrong because we have terrible intuition/gut-feel about Cost of Delay. We just don’t have the muscle memory. To much of the theory you see written about cost of delay (and duration for that matter) is based on a “Let’s assume” fantasy world that lacks real world understanding.
I’ve helped to quantify Cost of Delay in many different organisations – different teams, different products and all manner of projects and portfolios. I’ve seen this curve so many times now, that I’ve come to expect it, even though my little brain sometimes fights it. Through experience, I am slowly developing an intuition about Cost of Delay that I simply wasn’t born with. This is a muscle that needs training and exercise – an effort that most seem to want to avoid. Just like playing the piano with any degree of proficiency takes thousands of hours of extremely boring practice before developing the muscle memory required.
Thankfully, Cost of Delay isn’t anywhere near as difficult as playing the piano (at least in my experience of both). But, there is no shortcut, I’m afraid – no simple categorisation that get’s you there. You have to actually engage your brain. The good news is, this barrier to entry makes it easy to differentiate from your competitors!
Queues in Product Development are not inherently evil. Demand for developing new and improved products will always outstrip capacity. Most organisations attempt to make best use of that capacity based on a mix of numbers (like BCR or ROI), politics (equity/fairness/favouritism) and gut-feel (usually the HiPPO). Unfortunately, none of these have anything to say about the cost of queues. Without an understanding of Value and Urgency the system will optimise for something else – usually efficiency and certainty. This makes the queues worse and pushes work upstream in the process to where it is easier to hide and ignore – the “Fuzzy Front End”.
We’re getting better at visibility of queues, but what is missing is an understanding of the cost of queues. There’s no way around this but to improve our understanding of the Cost of Delay. This requires a better attempt at understanding both value AND urgency. Give it a try.
Without information about value and urgency, the system will (of course) optimise for other things.#CostOfDelay pic.twitter.com/lbzCEZvF7r
— Joshua J. Arnold (@joshuajames) January 27, 2015