I ranted on 100% utilization a few years ago already. Let me add another thread to that discussion. We have a ton of everyday stories that show how brain-dead the idea of maximizing utilization is. Sometimes we can figure out how it translates to work organization as well. Interestingly, what Don Reinertsen teaches us is that queuing theory says exactly the same.
As we go up with utilization lead time or wait time goes up as well. Except the latter grows exponentially. It looks roughly like that.
But wait, does it mean that we should strive to have as low utilization as possible? I mean, after all that’s where lead times are the shortest. This doesn’t sound sensible, right?
And it doesn’t make sense indeed. Cost of waiting is only one part of this equation. The other part is cost of idle capacity. We have people doing nothing thus they don’t produce value yet they cost something. From that perspective we have two cost components: delay cost related to long lead time and cost of idle capacity related to low utilization.
Of course the steepness of the curves would differ depending on the context. The thing is that the most interesting part of the chart is the sum of the costs which, naturally, is optimal at neither end of scale.
There is some sort of economic optimum for how much a system should be utilized to work most cost efficiently. There’s very good news for us though. The cost curve is the U-curve with flat bottom. That means that we don’t need to find the ideal utilization as a few percent here or there doesn’t make a huge difference.
We’d naturally think that the optimum is rather toward the more utilized part of the scale. That’s where the interesting part of the discussion starts.
We have pretty damn good idea how much idle time or slack time costs us. This part is easy. Now, the tricky question: how much is shorter lead time worth?
Imagine yourself as a Product Owner in a funded startup providing an online service. Your competitor adds a new feature that generates quite a lot of buzz on social media. How long are you willing to wait to provide the same feature in your app? Would keeping an idle team all the time just in case you need to build something super-quickly be justified?
Now imagine that your house is on fire. How long are you willing to wait for a fire brigade? Would keeping an idle fire brigade just in case be justified?
Clearly, there are scenarios where slight differences in lead time are of huge consequences. We don’t want our emergency calls to be queued for a couple of weeks because a fire brigade or an ambulance service is heavily utilized. In other words steepness of one of the curves varies a lot.
Let’s look how different scenarios change the picture.
This sets the economically optimal utilization at very different levels. There are contexts where a lot of slack is perfectly justified. The ultimate example I can come up with are most of armies. We don’t expect them to be fully engaged in wars all the time. In fact the more slack armies have the better. Somehow we don’t come up with an idea that if an army has no war to run we better find them one.
Of course it does matter how they use their slack time, but that’s another story.
We don’t have that drastic examples of value of slack in software industry. However, we also deal with very different steepness of delay cost curve. Even if we don’t expect instant delivery we need to move quicker and quicker as everyone else does the same.
The bottom line is that our intuition about what is the cost of wait time (delay cost) is often flawed. This means that even if we are able to go beyond the myth of 100% utilization we still tend to overload our teams too much.
Oh, and if you wondered, at Lunar Logic our goal is to keep team’s utilization between 80% and 90%.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
8 comments… add one
Hi Paweł,
A few questions came to mind:
How do you measure the utilization?
Are teams aware of their slack time?
How do people use their slack time, pet projects, sth else?
@Scooletz – Measuring utilization would look differently on different levels. On a project level it is simply whether someone is on a project (typically but not always that means billed work) or not. This is the most interesting for me at Lunar.
The other level of measuring slack would be within a project team. It’s not all the time that people do something planned. But then it’s trickier to define what exactly is slack time and what isn’t. For example: I’m a developer and instead of starting a new feature I go help with testing. Is that slack time or not?
An informal definition I use is that whenever we do something that we wouldn’t normally do, typically because of WIP limits, it is slack time. So if I didn’t start a new feature because of WIP limit in development station that’s slack time.
I don’t measure such slack time on that level though. The main goal on that level is to get the flow of work smooth and tweaking WIP limits usually does the trick. Also, with fine-grained work items, i.e. features, the outcome of optimizing utilization is limited.
However, when we discuss coarse-grained work items, i.e. projects, that’s the whole different discussion. If my utilization doesn’t allow to start a new attractive project we’re talking about significant financial consequences (of course given the context of the company). That’s exactly why I track utilization on that level.
You ask about awareness. For so called project slack (project-level work) they certainly are. That’s pretty much obvious whether you are on a project or not. For everyday slack I’d say some people are and some not.
The trick is, that on that account we aren’t a typical company as the ideas of limiting work in progress and slack time are so internalized by people that they don’t treat that as a special way of working or even have a need to label it somehow.
Finally, we have only one rule regarding how people can use their slack time – however the hell they want.
I strongly recommend such a strategy although of course a prerequisite is a healthy degree of trust. Many organizations either constrain slack giving the available options to choose form or proposing a preferable ways of using slack time.
I read this as a plea to spend the slack decreasing the intersection angle between the cost measure lines, thus smoothing total cost of utilization. This means our “Economically Optimal Utilization” reality is lower than what we can charge until our competition catches up, thus increasing current margin.
Then, when we do need to lower process, we can do it painlessly, because we already have lower costs and don’t have to invest in them.
As my drill sargeant used to say, “You got time to lean, you got time to clean.” Clean house in slack time and high demand time is facr less stressful and can even be more profitable.
If that’s your thesis here, I dig it.
@David – I don’t make a point here how one should use slack time. I like your metaphor of “you got time to lean, you got time to clean” though.
In fact, often in discussions I make a point that often ways to decrease utilization are exactly the ways that change the economic model of the equation, e.g. make delay cost curve more narrow, and thus change the balance of the equation even more.
Another example is yours — using slack to improve efficiency allows to shorten lead times which typically gives us advantage over the market.
That is a whole another discussion though. Maybe a candidate for a follow up post.
Personally I think a real Scrum Environment (small packages of functionality and continuous delivery) can help to reduce delay costs and maximize the utilization. You are able to change priorities every 1-4 weeks when market is changing.
The more traditional the project approach is, the more risk there is in maximizing the utilization.
@Franc – While small and frequent deliveries provide an advantage over big batches of work, it has nothing to do with economics of utilization. It is so in queuing theory. It is so in everyday life (does it matter whether a processor of your notebook is occupied with thousands of small tasks or one enormous computation when it’s 100% utilized?). It is so in our workplaces.
The difference is that frequent deliveries give you more liquidity in planning and prioritizing incoming work, but that’s pretty much it. Average lead times would be just as high.
Of course one consequence of above is that this gives us opportunity to optimize a little bit delay cost but given how rarely we are even able to assess Cost of Delay for the work items we work on it is rather virtual win.
@Pavel nice post. In terms of measuring utilization, I would really appreciate your thoughts on what 100% utilization actually means from your perspective i.e. on annual level, I assume from all working days you deduct annual leaves. Do you also deduct some training time, company coordination or something like that? Thank you.
@Nikola – I look at utilization from a daily perspective. In other words I don’t want a situation that at any given time everyone is working on a hard commitment. It can be translated to a task level, i.e. I want people to have slack within a project while working on different tasks. It can be translated to project level too, i.e. I want to have slack in portfolio so that people have spare time between project and at the same time I have options when something unplanned pops up.