Why Overloading Your Agile Process With Too Much Work Destroys Efficiency and Predictability
Predictability in software development is important—not just for estimating how long things will take, but because an unpredictable process is often highly inefficient. One of the key contributors to this inefficiency is having too much ongoing work at the same time. The reason this happens, as Donald Reinertsen explains in The Principles of Product Development Flow, is because:
It is easier to start work than it is to finish it. It is easier to grow work in progress than it is to reduce it.
The problem arises because starting new work feels productive and is often encouraged, especially when teams are pressured to show progress. Additionally, working on many things at once is often mistakenly seen as a good thing. But this strategy of taking on too much at once doesn’t work.
In this post, I’ll explain why trying to do everything at once is a fundamentally flawed strategy and why it’s so important to create an environment where teams have the space to complete ongoing work before starting yet another task from the backlog.
What Software Development and Busy Highway during rush hour have in common?
Think of a highway you regularly travel. When traffic is light, cars move smoothly and predictably, allowing you to estimate how long your trip will take with confidence. As the number of cars on the road increases, throughput (the number of cars passing a point per unit of time) also increases—up to a certain point. However, beyond that optimal point, adding more traffic leads to congestion. When the road becomes overcrowded, travel times become highly unpredictable and significantly longer.
Queueing theory explains this phenomenon. When more traffic is added to a road already operating at maximum throughput, throughput quickly slows down. If the problem isn’t addressed and more cars continue to enter the highway than leave it, congestion occurs. This phenomenon follows a parabolic curve, where throughput is maximized at an optimal density and speed of traffic. Beyond this point, throughput deteriorates rapidly as capacity becomes overloaded, causing significant delays and unpredictability.
As Donald Reinertsen explains in his work, this same pattern occurs when software development teams take on new work when they are already operating at their optimal throughput. When teams start new work while already having enough on their hands, they extend the list of work in progress instead of focusing on completing existing tasks. This creates congestion that severely limits throughput.
Just like traffic on a congested highway, when one task encounters an issue or delay, it can trigger a cascade of delays across other tasks. This ripple effect increases the variability of cycle times and makes accurate forecasting nearly impossible. As Reinersten describes in The Principles of Product Development Flow, operating at high levels of capacity utilization doesn’t just slow down progress—it also increases cycle times and drastically reduces the efficiency of the entire workflow.
The Solution is simple - but challenging to implement
Just like traffic on a congested highway, the only way to restore maximum throughput and achieve predictable flow is to reduce the number of cars on the road. This happens when the number of cars entering the highway drops below the number of cars exiting—reducing congestion and allowing traffic to flow smoothly again.
The same principle applies to software development. When your development process is overloaded with too much work in progress (WIP), the only way to combat this issue is by actively limiting your WIP. By doing so, you create enough breathing room to absorb variability and maintain a smooth flow.
What To Do When You’re Stuck in Congestion
If your development pipeline is overloaded with too much WIP, here’s how to start solving the problem:
- Stop Starting New Work: Instead of constantly adding new tasks to your workflow, focus your team’s effort on completing existing work in progress.
- Define WIP Limits: Establish clear WIP limits that allow your team to run at optimal throughput. Only start new work when you are within those limits.
- Continuously Monitor Key Metrics: This allows you to maintain optimal flow by providing clear visibility into state of your process. Monitoring the following metrics gives you objective data to push back against the constant pressure to start more work.
Metrics to monitor
- Work in progress (the number of items your teams are working on at any given time)
- Cycle-time (how long it takes each of those team to get through your dev-process)
- Throughput (how many work items complete per unit of time) -- Only start new work in line with your WIP limts
The key is to only start new work in line with your WIP limits. By respecting these limits, you create a stable environment where tasks can flow smoothly and predictably—just like traffic moving efficiently on a highway operating at optimal throughput.
Unlike traffic, where the number of cars entering a highway is not controlled, in software development, you have the ability to decide when new work starts. However, implementing this control is challenging because there are many forces pushing in the opposite direction—stakeholder pressure, conflicting priorities, and the belief that having more work in progress means more progress is being made.
Why Limiting Work in Progress Is So Hard to Implement
Understanding the theory and actually implementing WIP limits are two very different things.
The real obstacles aren't technical—they're organizational: leadership resistance, cultural beliefs that equate "busy" with "productive," misaligned incentives that reward starting work over finishing it, and relentless stakeholder pressure to do everything at once.
These challenges require specific strategies to overcome. I've written a comprehensive guide that breaks down each source of resistance and provides proven techniques to address them: Why Your Team Will Resist WIP Limits (And How to Overcome It).
Having the right data and insights makes it much easier to stay on track, which brings us to...
