Traditional management approaches have often put high resource utilisation levels at the top of managers agenda as a recipe for effective management, assuming that existing not fully utilised resources are waste. When managers do capacity planning, they focus on utilising all the resources they have to the max, and this approach has often been considered a universal best practice among managers.
For the purpose of this article a resource is a person that works within a team on a product.
Now, let’s have a look at a system where 100% utilisation works well:
Think about an oil pipeline. It would be really wasteful to build a massive pipeline and just push a little quantity of oil through it. Engineers will calculate the optimal pressure and volume of oil that can be moved and the oil will fill the pipe in a constant stream. That’s what I refer to as 100% resource utilisation.
Based on a similar principle, management believe that they should utilise all their resources 100% so that they can push through a stream of value to be delivered to our customers.
So, what’s the problem? You might say. It is easy to agree with that approach but the issue is that by applying the laws of fluid dynamics to people delivering value through software, we underestimate the impact of variability. Human beings introduce levels of complexity and variability that are of an order of magnitude higher to the ones found in an oil pipeline. Oil will flow in a pipe at a steady pace at 100% utilisation, on the other hand a system made of human beings delivering value through software will be affected by countless variables and will not work the same way at 100% resource utilisation.
So, for a better comparison with software development, let’s use a system that is slightly more similar to a software delivery team than an oil pipe is because it includes human variability. Let’s use traffic flow.
Let’s now look at what happens when we try to get 100% utilisation, that in traffic terms means all lanes used with as close to constant as possible flow of vehicles. Human variability factors in this time include for example a driver that gets distracted and doesn’t move when there is space in front of him, or a car that breaks down, or a driver that tries to overtake in between lanes or even a driver that falls asleep at the wheel. The result is something like in the picture to the right.
What’s efficiency for a traffic system? I am simplifying but the throughput of cars would seem to me as a good metric. So let’s say that our measure of efficiency is C/h = number of cars that go through a section of the road in one hour. A traffic jam implies low throughput and high cycle time.
We have all been in a traffic jam and we should know that it is certainly not the most efficient way of using the capacity of the road. When you are in a queue and are not moving, you are not being efficient, you are wasting time and petrol. Starting and stopping is not efficient either as, when breaking, you waste your momentum you gained when accelerating, burning petrol and breaks.
Now look at the picture on the left and tell me, is that more efficient than the traffic jam? Will the C/h of the second picture be higher or lower than the one in the first one?
Believe it or not, the answer is higher.
But, we are not using all our resources! Look at that unused space between cars, surely this can’t be right!
Now look at the two pictures below and see if you can identify similarities with the traffic system.
This is a simple visual representation on how 2 similar systems can obtain higher throughput by limiting the work in progress (cars in transit). It is a counter intuitive idea, but limiting the amount of cars that can be on a road at the same time, can increase throughput. Similarly you can increase your software delivery throughput by limiting work in progress. For the moment I am going to leave it for your imagination to think and speculate whether this is true or not. In the next chapter of this blog post I will use mathematics to demonstrate it. Stay Tuned.