Why busy teams are slow.
Keeping everyone busy feels efficient, but queueing math says it makes delivery slower. Here’s why, and what I’d change in how teams plan their work.
By Nizar Oukhchi, Solution architect
Published · 7 min read
Your team is late. So you do the obvious thing: you make sure everyone is busy.
You fill every sprint. You start the next project before the current one ends. You keep every developer's backlog full. It feels efficient.
So why does everything get slower?
It's not motivation, and it's not skill. It's math. Factories and telecom networks figured it out decades ago, and I think most software teams (me included, for a long time) still plan as if it didn't exist.
Let me walk you through it.
Work spends most of its life waiting
Think about what happens to a request when it reaches a team.
It rarely gets worked on right away. First it waits for someone to be free. Then it waits for a review. Then for a test environment, a decision, or a deployment slot.
In most teams, the time a piece of work spends waiting is much longer than the time anyone spends actually working on it.
There's a whole field that studies how those waits behave. It's called queueing theory, and its central result is simple to state:
As a resource gets close to full utilization, the wait in front of it doesn't grow steadily. It explodes.
Here's what that looks like:
| Team utilization | Wait |
|---|---|
| 5% | 0 × |
| 10% | 0 × |
| 15% | 0 × |
| 20% | 0 × |
| 25% | 0 × |
| 30% | 0 × |
| 35% | 1 × |
| 40% | 1 × |
| 45% | 1 × |
| 50% | 1 × |
| 55% | 1 × |
| 60% | 1 × |
| 65% | 2 × |
| 70% | 2 × |
| 75% | 3 × |
| 80% | 4 × |
| 85% | 6 × |
| 90% | 9 × |
| 95% | 19 × |
Let's read the curve in the simplest model.
At 50% utilization, work waits, on average, about as long as the work itself takes. That's fine.
At 80%, the wait is four times the work.
At 90%, nine times.
At 95%, nineteen times.
Read that again. Those last few points of "efficiency" are paid for with weeks of delay.
This explains something that used to puzzle me. How can a team look fully productive and still feel slow to everyone around it?
Because both are true. Each person is busy. And each piece of work is mostly sitting still.
Uneven work makes it worse
Are we done? Not quite.
That curve assumes a moderate amount of randomness. Software work is often messier. Some tasks take an hour, others take two weeks. Urgent requests show up without warning.
There's a standard approximation in queueing theory called Kingman's formula. It shows that the wait scales with this variability, not only with load.
Here's the same 85% utilization, with three different kinds of work:
A team with steady, similar-sized work waits about half as long as the reference case. A team flooded with urgent interruptions and very uneven tasks waits about twice as long.
Same load. Very different wait.
And the two levers multiply each other. High load combined with high variability is where delivery stalls.
Less in progress, faster delivery
Now for the good news.
There's a result called Little's law that holds for almost any stable system. It links three numbers:
average lead time = work in progress ÷ throughput
Say your team finishes ten items a week and has forty items open. Each item takes, on average, four weeks from start to finish.
Now look at what happens if you change only one number:
Did the team get faster? No. Throughput is exactly the same.
But lead time drops anyway.
You can shorten lead times without working any faster. Starting less work at once is enough.
Each item spends less time waiting behind the others, and feedback on it arrives sooner.
There are also benefits the formula doesn't show. People switch context less often. Problems surface while the work is still fresh in someone's head. Finished features start delivering value earlier.
What I'd change in planning
I want to be clear about one thing. None of this argues for idle teams.
It argues for planning with the curve in mind. Here's what that means in practice:
- Plan for 70 to 80% of capacity. The rest absorbs urgent fixes, reviews and the unexpected without stalling everything else. A team planned at 100% is already late on the first day.
- Limit work in progress. Set a cap on how many items can be in progress at once, per team or per stage. Finish work before starting more. A board with fewer cards in progress usually moves faster.
- Reduce variability where you can. Split large items into small, similar-sized ones. Send urgent requests through a dedicated, limited channel instead of letting them interrupt everything.
- Watch the queues, not the people. Measure how long work waits for review, testing and deployment. The longest wait is usually the cheapest place to gain speed.
For that last one, automation helps a lot. Continuous integration and one-click deployment remove several queues at once.
If you'll forgive a kitchen metaphor: a busy restaurant doesn't get faster by making every cook juggle more plates. It gets faster when plates stop piling up at the pass.
A note on the models
I should be honest about where these numbers come from.
They come from standard models with simplifying assumptions. They're not measurements of a particular team, and real teams are messier.
The shape, though, is robust. Waiting grows sharply with load. It grows with variability. And it falls when less work is in progress.
Teams that measure their own lead times almost always find the same pattern.
Where to start
Here's a small experiment.
For a month, measure two numbers: how many items your team finishes per week, and how many are in progress on an average day.
Divide the second by the first. Then compare the result with how long work actually takes to reach your users.
I'd bet the gap tells you something.
If the numbers surprise you, we'd be happy to help you find where your work waits. Our software engineering services include setting up the delivery pipelines that make those queues disappear.
Happy measuring!