Ever notice how a team can be slammed? Calendars are packed, Slack is on fire, and yet the same important work is still "almost done" for weeks. Maybe it's just me. But I have a feeling that it's not a capacity problem like most people think. Perhaps it's a constraint problem. And when everything is in progress, it seems like nothing ever finishes.
Ever paint a room? It's 80% done for weeks. So a busy system usually delivers less value, but a lot more inventory of work. Now, is that a good or a bad thing in our line of agile work?
Hi, I'm Lance Dacy, otherwise known as Big Agile. And today we're going to be talking about constraints, not capacity, and talk about why your busy team delivers less value perhaps, and what to do about it.
We're going to cover three things: how bottlenecks actually work, why utilization is a trap, and a simple way to cut delivery time without hiring a single person. Then we're going to preview building the rest of the week because this topic is the root cause behind most of our Sprint review problems.
Busy Is Not the Goal—Outcomes Are
I find that most organizations try to go faster in one of two ways. First of all, we'll start more work. We'll parallelize it. We'll add people. We'll just need more capacity. Both are emotionally satisfying. I've sat in a leadership chair and made those decisions, but both are typically wrong because delivery and product development is not necessarily a headcount problem—it's a flow problem. And flow is controlled by constraints.
If you want more hamburgers flipped on the griddle, by all means, add more people. But if you want more usable software delivered to the end users, focus on flow.
The Data Backs This Up
DORA research has been consistently clear over the years that performance is not about heroics or Superman. It's about the systems. And in 2024, they've really framed that performance in terms of throughput and stability while emphasizing the importance of stable priorities and user-centric outcomes. It's exciting to me to have this data because we always felt it, we kind of knew it, but the data just helps us articulate it better.
Constraints 101: One Slow Step Sets the Pace for Everything
Some of you might be new to this world of product development. So here's the most basic truth in my experience: the system delivers at the speed of the bottleneck, not the average speed of everybody in the system.
In Agile, we often teach leaders to form cross-functional teams, feature teams if you will. It is not an easier way to work, by the way. And it's likely to face significant pushback from engineers and engineering leaders. You'll be on an island when you try to articulate that. They like working with people of the same skills. I was in that boat too. I mean, it feels faster to them at that lower level of work.
Unfortunately, they end up producing just a lot of inventory items that must be passed on to another team. And so now your customer is watching that and waiting in a relay race for that last person to cross the finish line or that last team.
The Invisible Warehouse Problem
In software, I find inventory is really hard to see. In retail, it's not. In retail, you want just-in-time inventory. I don't want things sitting around a warehouse. I want them on the shelves being sold. In development, we want the same thing. But where is the warehouse? And how can I move the items into the stores to be sold? That's your end user.
If you want to optimize for that end user delivery, which in Agile we typically do, focus on the baton, not the runners. Reduce the shelved inventory in the warehouse and get it out to the customers.
A Real-World Example
Look at the team that I just worked with last week. We had 12 engineers, three testers, one security compliance reviewer, and one person who was the only one who could approve production access. Now, their delivery system is not 16 people strong. The delivery system is only as fast as the slowest constrained step.
Let's not focus on how large that team was—that's another topic. But when we ignore the constraints of that person who can approve to production or the one security reviewer, we do something very predictable. We keep feeding it more work. Or worse, we optimize the team at the local level, essentially sub-optimizing the system.
What that'll end up doing is create a queue, and that queue creates a delay. And what happens with that delay is it often gets misdiagnosed as "people are slow." So go ahead and start more work so they can catch up. Schedule more meetings, crank up the utilization to 100%.
Congratulations when we do that—and I've done it before as well—you just built a traffic jam, and then you blamed all the cars for the traffic jam.
Why Utilization Is a Trap
Leaders love that metric. It feels efficient, especially if you're a consulting group. You want everybody utilized. If everyone's busy, it looks like we're getting money's worth for the salaries that we're paying. But in flow-based economics, max utilization is how you generate and guarantee max waiting.
In product development, we kind of call this the cost of delay, and that is usually far more expensive than the cost of a little bit of slack in the system that we're uncomfortable with.
The Hidden Costs of 100% Utilization
Donald Reinertsen emphasizes this point from an economic perspective: queues are not harmless. They are quite expensive. So what happens when you hit that ceiling of the queues and the 100% utilization?
- People start to multitask
- Handoffs increase
- Work waits longer between steps
- Defects escape because everybody is rushing
- Cycle time stretches
- Predictability drops
- Leaders request additional status updates, which just consumes more capacity and slows down delivery
You go to the meeting before the meeting, before the meeting, right? It's the corporate version of stepping on the gas while you're in the mud or in the ice like we were this last week. If you're a technology person, I typically call that recursive—recursion, you know, a recursive function, a function of itself.
A Simple Numeric Example: Little's Law and Work in Progress
I want to do an example of Little's Law. And I promise to keep it human, but Little's Law is a law. It's basically the idea that:
Cycle Time = Work in Progress ÷ Throughput
- Work in progress is essentially how many items are in progress or started but not finished
- Throughput is how many items you finish per unit of time
- Cycle time is how long an item takes on average from start to done
The Math That Changes Everything
Imagine a team that finishes five items per week on average. If we take the formula, we're going to have 20 work items:
20 ÷ 5 = 4 weeks
You don't feel that in a status meeting because everybody looks busy, but your customers feel it. I guarantee it.
But if we were to cut work in progress in half to maybe 10 items and throughput stays the same, then we could change that formula to be something like:
Cycle Time = 10 ÷ 5 = 2 weeks
Same people, same talent, same calendars, by the way, but just faster delivery or sooner delivery. But perhaps more slack time at the individual level—that's the trade-off.
Micromanagers or sub-optimizers, project managers, they see additional slack time in individuals and claim we aren't productive. Well, I guarantee you the customer disagrees. But who's right?
That's the essence of constraints thinking. And we say it all the time in Scrum training: stop starting and start finishing. And by the way, real life is usually even harsher than this example that I'm giving because variability makes those queues explode. I didn't have a whole lot of variability in here, but in the real world, you will.
That's fundamentally why busy teams often deliver less, not more work—more inventory.
Bottlenecks Are Rarely a Person—They're Usually a Policy
This is where I see leaders get a little bit twitchy because we love to find the bottleneck engineer and then fix that person. Who's slowing us down? Who's the slowest person in the queue?
But most constraints in software organizations are policy constraints, not human constraints. And those policies can manifest themselves in many ways:
- Too many concurrent projects at a time
- Too many approvals
- Priorities that are changing every week
- Shared services that have no intake policy
- Security reviews that start late
- Release processes that are manual and fragile
- Leadership that is rewarding busyness, not outcomes
Does that sound familiar? It's very common.
The Real Leadership Move
The leadership move is not to pressure the team and say, "Go faster." That's going to create a lot of problems. The leadership move is to find the constraint, protect it, and reduce the queue in front of it.
Our teams would likely love to do this, but they're simply too busy or, worse yet, not empowered to make that move. So leaders need to help with this.
Your Practical Playbook: What to Do This Week
Here's what I'd like you to test. Yes, they're old school, common sense, dressed up in modern flow economics.
1. Identify the Constraint with Evidence, Not Feelings
Go look at it, go get the data. Ask your teams or ask people:
- Where does the work wait the longest?
- Where do we see the biggest pile-ups?
- What steps cause the most rework?
If you're guessing and you don't have the data, then you are gambling with your stakeholders' business objectives. So let's go figure that out.
2. Protect the Constraint
Stop treating the constraint like a shared public park. Give it a clear intake policy. Limit interruptions for it. Make work ready before it enters—product backlog refinement. Put a small buffer in front of it, like limiting how many items we're going to do with this.
3. Reduce Work in Progress Limits Aggressively
Have people start swarming the work. If everything is important, nothing is. So everybody's working together—get the one or two things done before they start something else.
Start a work in progress limit at the team level and key workflow states like in progress, in review, in test, waiting for approval so that we can see these things. Kanban tells us to do this a lot.
This will feel uncomfortable at first because it exposes the truth that you have more demand than capacity. That's probably the root problem. So good. Now you can go manage it like adults. My family is spending more money than I bring in. Does that sound familiar?
4. Stop Rewarding Multitasking
If your recognition system celebrates the person that's on seven initiatives, then you are just paying people to create queues.
Start looking and find people doing things approximately right. Celebrate people finishing work, unblocking work, reducing cycle time, improving stability, and saying no to nonsense work.
5. Stabilize Priorities
As a leader, another thing we can do is stabilize priorities. DORA underscores the importance of stable priorities for organizational success. If priority shifts, then flow typically collapses with it.
A simple rule that I live with and many leaders can live with, try this: if you want to start something new, you or your stakeholders midstream, you must stop something of equal size. And then also make sure to account for the context switching, the transactional costs of the start-stop activities. Build those things in so we can see them.
What's Coming This Week
This YouTube video is just really my overview to kick off the week. Here's where we're going to go next. If you're not part of our premium email, please feel free to subscribe to that.
- Tuesday (Premium Email): Bottleneck coaching—the conversation that leaders avoid and how to name that constraint without blame, plus a two-week experiment that might help you protect flow
- Wednesday (Public Blog): Breaking down the cost of multitasking, signs of overload, corrective actions, and a starter work-in-progress policy that you can roll out without hiring a bunch of consultants
- Friday (LinkedIn Newsletter): Saying the quiet part out loud—you don't have a speed problem, you have a focus problem. We're going to be blunt, be kind, and talk about finishing as the new goal
The Bottom Line
If your team is busy, you're probably losing. If your team is always busy and delivering is still disappointing, don't assume you need more people. Assume that you have too much work in progress. Assume that you have too many queues, you have unstable priorities, and a constraint that you keep starving, interrupting, or worse, drowning.
Fix the flow. Then the capacity can and will be able to behave like a multiplier.
Ready to Transform Your Team's Flow?
If you want help bringing this into your organization, we have public courses and private courses, and that's what we do here. What is your specific issue and how can we start moving you across that finish line?
Check out our courses and coaching, and we'll do our best to help you identify the constraint, limit your work in progress, set those limits, and help you build a system that delivers predictably without burning your people out.
Just remember this: change is hard, but staying stuck is way more expensive and even harder.
Happy constraint hunting. We'll see you next week.