Why Overloading Developers Never Works

Blame yourself if your team fails to deliver despite working their fingers to the bone.

We all have been in this situation before. A tight deadline looms. We add a way more work to the Sprint than we should based on our average velocity. We feel good when we do this. Our team will now take care of it. It is out of our hands. The development team will put in the extra work necessary. Because whatever happens, we must make the deadline and complete the scope.

Our team works extremely hard to deliver the Sprint. Despite the hard work, the last day of the Sprint almost nothing is finished. It even seems the team is stuck in quick-sand. The harder they work, the less gets done.

How is this possible?

Relationship Between Being Busy And Wait Time

Imagine you arrive at a supermarket with a single cashier. You see the cashier is never idle and always occupied with customers. If the cashier never has to wait for customers, this automatically means any arriving customers have to wait. There is a clear relationship between how busy the cashier is and customer wait time.

Just like when you are overloaded at work and somebody taps your shoulder to ask if you can help. The moment this happens you feel stressed and think: I do not have time for this. Either the person who asks for help waits or someone else has to wait.

Hospitals historically focus on maximizing the utilization of resources and do not care about waiting time as much. Doctors are expensive and their time is valuable. Medical equipment is costly and the hospital cannot afford more machines. What is the result for the patient? Surprise, surprise: insane waiting times. Hospitals are fine with having you wait as long as their scarce and expensive resources are happily chugging along. Except cases where fast treatment is essential of course. This is where triage comes into play.

Why Does Wait Time Matter?

Imagine you are the proud owner of a pizza delivery service. Your pizza is the best in the city, so people are always calling. You have three employees: a front-office employee, a pizza guy and a speedy delivery man. If all of them are 100 percent busy while ignoring flow, what would happen?

People would start calling. Where is my pizza? Customers will tell their pizza arrived cold. Now you need to send another pizza or give a refund. They will try to reach you, because they are waiting so long they no longer want the pizza. The phone is so busy that the pizza guy actually starts picking up the phone as well. And then there are actually less pizza’s being produced, which results in less being delivered and more phone calls… you get the point. You will lose customers and money. Everything will grind to a halt.

The example above is a bit extreme, but waiting comes at a cost which may or may not be immediately visible. In software development waiting also has negative consequences.

A ticket which is on backlog too long means the customer may call to ask how it is going. By the time you pick the ticket up it may have become obsolete and needs be updated or closed. A ticket in code review for too long actually now has unresolved merge conflicts that need to be fixed before it can be reviewed. A ticket in test for too long has to be reopened because new functionality has been released which conflicts with the ticket. Now additional rework is necessary. A ticket that waits incurs costs that are often not easy to spot.

Software Developer’s Dilemma

If you focus on keeping your developers as busy as possible, then the wait time for any issues they work on shoots up. This means less work will be completed due to congestion. Waiting costs are introduced that affect productivity. Developers need to switch more between tasks which introduces switching costs.

If you concentrate on completing individual issues as quickly as possible, your developers will become bored as they are under-utilized. A manager will likely come in to ask questions why there are so many developers not writing any code.

If resource or flow maximization both do not work very well, what is a viable alternative?

Striking The Right Balance: Resource Efficiency Vs. Flow Efficiency

Before we can start answering this question, let’s start with some definitions. Something or somebody able to perform work is a resource. If a resource is busy all the time it is able to perform work, then the resource efficiency is 100%. The resource efficiency metric looks at performed work from the perspective of the resource. What percentage of the time does the resource add value to one or more flow units?

The item work is performed on is called the flow unit. Flow efficiency looks at work performed from the perspective of the flow unit. What percentage of time does the flow unit receive value?

Resource efficiency = (Idle time / busy time) x 100%.

Flow efficiency = (Value adding time / total time) x 100%.

When you you map resource efficiency against flow efficiency you get the following two by two matrix.

Wasteland

This means that resources are under-utilized and the wait time for flow units is high. This is a terrible place to be in as you suffer the worst of two worlds.

Concrete examples: applying for social security number (NIE) at Catalan government, getting a VISA at USA embassy in The Netherlands.

Efficient Islands

Resources are utilized as much as possible, flow unit wait time is high. This is a better place to be in, but still not very great.

Concrete examples: checking in at the airport, visiting the hospital when you are not an urgent case.

Efficient Ocean

Resources are under-utilized, flow units spend little time waiting.

Concrete examples: Business Class line at airport, reception desk of expensive apartment complex.

Perfect State

Resource have high utilization and wait time on flow units is low. This is the holy grail few companies achieve.

Concrete examples: Uber, Deliveroo.

Getting To High Resource And High Flow Efficiency

It is better to focus first on getting the flow right and then scaling up resource efficiency from there. The path to high resource efficiency generally looks as follows:

You should first focus on increasing your flow efficiency. This means your resource efficiency will be very poor. Then as your flow efficiency increases, you should start paying attention to scaling up resource efficiency. Getting there is tough and in the beginning your productivity will be lower. The key is to hang in there and slowly work towards the optimal situation. Viewing performed work through a lean lens will help to achieve desired situation.

Conclusion

Organisations traditionally focus on resource efficiency. This fits with the factory mindset of keeping machines running at maximum capacity. Intuitively people assume that busier people produce more. Making resources as busy possible without regard to flow, lowers productivity and comes with (hidden) costs. Organisations should focus on flow efficiency first and increasing resource efficiency should be a secondary objective. In the beginning this will seem counter-intuitive, but in the end it will pay off.

Further Reading