Your team has capacity. Your system might not.
There’s a familiar ritual when delivery starts going wrong. Something is late; a date looks increasingly like a work of fiction; work is ageing; stakeholders are getting twitchy; and someone has moved the status from green to amber (how large organisations traditionally acknowledge the existence of physics).
And everybody starts to look to the delivery team.
Can they go faster? Can they estimate better? Can they make the work smaller? Why is that story blocked? Should we add a few more people? Do we need another daily meeting? Should we mandate weekend work and overtime? Perhaps, if things are really serious, a dashboard for management with hourly updates.
There are some perfectly reasonable questions in that lot, but the real problem is we’re just asking them several months too late. In my experience, by the time work reaches a delivery team, most of the decisions that determine how well it will flow have already been made.
Things like:
- How much work the team already had in flight.
- Whether what is being added to the schedule is right-sized for the team taking it on.
- How many unresolved dependencies were ‘designed’ into it.
- Where it would compete for scarce services or specialist skills.
- What assumptions were quietly converted into facts.
- What dates were promised.
- How much other work was already pushed into the system alongside it in the same area.
The delivery problem didn’t start in delivery. It started when we decided to start one more thing.
The organisation that limits WIP. Sort of.#
We’ve become skilled at telling teams to control work in progress and actively manage work; you may have said some of the following yourself:
- Put your defined WIP control mechanism on the board.
- The way to stop work ageing is not to start it, or to finish it.
- Swarm around ageing work.
- All things being equal, always work on the oldest item first.
- Don’t pull something new in if you can help finish something else already started.
Excellent advice, but then something curious happens a few levels up: we gather senior leaders in a room once a quarter and ask a rather different question.
What else should we start?
Twenty-seven initiatives later, we congratulate ourselves on having aligned the portfolio. The teams now have too much WIP, obviously, but we will get them some coaching.
At the team level, we understand that starting more work doesn’t get more work done (hat tip to Little). At the portfolio level, however, starting things still looks suspiciously like progress. A new initiative has a name and a sponsor. It has an ‘impact’ slide in one of our product managers’ decks. If we’re really committed, it might have its own acronym. Finishing something, meanwhile, mostly creates capacity, and capacity is considerably harder to photograph, or even count, for the town hall (we call that slack, don’t we?).
So portfolios get very good at selecting work and remain remarkably bad at managing its flow once it’s been selected. This produces something seductive: an organisation that looks extraordinarily well managed while creating terrible flow.
Quick check:
- Everything has an owner.
- Everything has a priority.
- Everything has a target date.
- Everything has a team assigned.
- Every dependency has been documented.
- Every team is fully allocated.
Perfect. We’ve built a completely overloaded system and documented it beautifully.
The roadmap is immaculate. The governance is in place. The capacity spreadsheet has precisely 100% of everyone allocated because, apparently, human beings are hot-swappable processors and context switching is free. There are steering committees, status reports, and dependency logs, and possibly a PMO that maintains them.
Everything is under control. Apart from the work.
Capacity to start is not capacity to flow#
“Team Alpha has capacity.” Excellent. Let’s get them started on the next thing. We’ve ticked the box marked capacity planning.
Unfortunately, nobody told the work. Because the work doesn’t just visit Team Alpha. It goes on a small tour of the organisation. First Identity. Then Platform. There’s an integration change. Data needs to do something. Security would like a word. There’s a shared test environment. And eventually, someone called Dave has to approve something, but Dave is currently the critical path for approximately half the organisation.
Team Alpha had capacity to start. That tells us nothing about whether the system has capacity for the work to flow. Those are very different things, and most portfolio planning only ever measures the first.
To be fair, nobody sits in a room and concludes that a free team means a free system. There’s no faulty reasoning to correct here, because there’s no reasoning step at all. Free team, important work, off we go.
And team capacity isn’t the wrong thing to look at. It just isn’t enough on its own. If the new work travels nowhere near anything that’s already congested, starting it is fine. The failure is the question nobody asks afterwards: what does this work touch, and is anything already queuing there?
Without that question, we’re adding cars to a motorway because there’s plenty of space on the slip road, only to seem genuinely surprised by the traffic jam.
Now picture a portfolio with fifty epics already in flight, and someone proposes another. It’s important, naturally; they always are. But this one is a strategic priority, which apparently means Little’s Law no longer applies. And besides, it’s only one more epic. One more thing for Platform. One more thing competing for the test environment. One more thing can’t hurt, can it?
Except everybody has a “one more thing”, and the system experiences all of them at once.
The conversation focuses on the new thing. What’s the opportunity? What’s the business case? Which team can take it? And if that team appears to have room, we’re off. The question that gets asked far less often is what starting this does to the fifty things already in flight.
Because those fifty aren’t independent work items moving serenely towards completion. They collide. Eight need changes to the same platform. Six need the same integration capability. Four need the same specialist. Twelve eventually need the same test environment. Half need security, architecture or data at roughly the same point.
So the useful question isn’t how much WIP we have; it’s where that WIP is competing for the same service capacity.
That’s service contention, and it creates queues, and queues are where flow goes to die.
The platform team isn’t slow. The integration team isn’t inefficient. The specialist doesn’t need a productivity workshop. We’ve created demand for a service faster than the service can satisfy it, so work waits, age climbs, throughput falls, and forecasts deteriorate. And because each initiative looked perfectly reasonable on the day we approved it, nobody feels particularly responsible for the queue we collectively created.
That’s the killer. Locally sensible portfolio decisions create globally terrible flow.
One more epic barely moves the headline WIP number. But if it’s the seventh piece of work needing the same constrained service, the impact is wildly disproportionate. That’s something a portfolio needs to understand before it pulls the work, not three months later when everything has turned amber and the delivery teams are asked to produce a recovery plan.
Here’s what that looks like when you actually measure it.
I recently ran a service contention report across a portfolio, mapping every active work item to the components it touched. Twenty-four components showed contention. Five of them carried most of it.
This portfolio has a service level expectation. Eighty-five per cent of its work items are completed in 23 days or less. That’s not a target anyone set in a workshop; it’s what the historical data says the system actually does.
So 23 days is the line. Past that, an item is behaving unusually for this portfolio, and the probability of it landing when expected is declining.
One component was needed by eight teams, had twenty stories sitting on it, and its oldest item had been open for 89 days - that’s nearly four times the service level expectation. On a component that eight separate teams were waiting on.
Look down that column. The only component whose oldest item was still inside the service level expectation had exactly one team on it. Every contended component had work that had blown through the line, and the worst of them was the one the most teams needed.
I’d stop short of calling that causation on five components. But the direction is hard to ignore, and it doesn’t need to be causal to matter, because the more uncomfortable finding is sitting in the last column.
Eight teams shared a dependency on a single component, and nothing in the governance layer indicated it. Not the roadmap. Not the dependency log. Not the steering pack. All five of those components were reporting green in the same cycle, because RAG status attaches to initiatives, and this particular risk doesn’t live inside an initiative. It lives between them.
That’s the failure mode. If that API slips, eight teams slip together. It’s one correlated risk wearing eight different initiative names, and the reporting structure has no way to add it up.
And none of this was a forecast. It was sitting in data the organisation already had. Nobody had asked the question.
Not every dependency problem is a dependency problem#
We talk a lot about dependency management, and sometimes that’s exactly what we’re dealing with. Team A needs something from Team B before it can proceed. That’s a dependency.
But when Teams A, B, C, D, E and F all continually need something from the same platform or specialist service, we have a different problem. We’ve built a shared service where demand arrives faster than the service can satisfy it. That’s a queueing problem.
We can manage it, of course. We can map the dependencies. Put them in Jira. Colour-code them. Create a dependency board. Appoint a dependency manager. And, naturally, schedule a weekly Dependency Forum where twelve people spend an hour discussing why six teams are still waiting for the same platform team. The queue will be delighted with all the attention.
None of it creates any more capacity in the constrained service. At some point, a dependency management problem is just a queueing problem with a job title.
This matters because the interventions are completely different. If it’s genuinely a one-off dependency, coordinate it. If it’s persistent contention around a service, we need to look at the system we’ve designed. Can we remove the dependency? Can teams self-serve? Can we change the interface? Can we add capacity at the constraint? Can we sequence demand differently?
Or, most radically: should we stop pulling work that requires the constrained service?
That’s a portfolio decision, not a delivery-team problem.
We talk about these dependencies as though we discovered them in the wild. “We’ve identified a dependency.” Of course, some genuinely are emergent - complex systems contain surprises. But many are designed. We create them through our architecture, our organisational boundaries, our specialist functions, our funding structures, the way we slice work, and solutions that require six teams to coordinate before a customer gets anything useful. Then we label them delivery dependencies and hand them to teams to manage.
There’s something perverse about designing a system that requires constant coordination and then measuring teams on how efficiently they coordinate around it. Maybe the teams aren’t bad at managing dependencies. Maybe we’ve built a dependency factory.
Big work starts big#
The same logic applies to batch size. We ask delivery teams to right-size their work, which is good advice, but there’s only so much right-sizing available after the organisation has already committed to “replace the customer platform by October”.
That’s not a work item. That’s a lifestyle choice.
Large batches begin long before anyone creates a story. A solution gets agreed. Funding gets attached. A date appears. Stakeholders align around the whole thing. Someone puts it on a roadmap, possibly with a nice arrow. Only then do we ask a team to break it down.
Technically we’ve decomposed the work. Economically, we’re still committed to delivering the entire batch. We’ve created lots of small tickets within one enormous promise, only to wonder why slicing the tickets didn’t change our ability to respond.
What if the portfolio behaved like a flow system?#
Instead of treating portfolio management as a periodic exercise in selecting and starting work, treat the portfolio as a flow system. Not another framework. Not another transformation programme. Definitely not another meeting. Just actively managing work after we’ve decided to invest in it.
What’s ageing? Are we starting faster than we’re finishing? Where is service contention appearing? Which shared capabilities are accumulating queues? Is scope growing? Is the probability of hitting an important date improving or deteriorating? Where is our capacity actually going? What have we learned since we made the original decision?
None of these are exotic signals. But they change the conversation.
Instead of “are we on track?”, we can ask what our likelihood is of hitting the target. Instead of “why has the date moved?”, we can ask what changed in the system. Instead of “which team has capacity?”, we can ask where this work will compete for capacity.
And instead of “what should we start next?”, we can ask whether we should start anything at all.
That last one takes some getting used to.
If you want something concrete to begin with, try this. List your active initiatives down one axis and your shared services down the other - platform, integration, data, security, architecture, test environments, the individuals everyone queues behind. Mark every cell where an initiative will need that service. Then count the marks in each column.
The columns with the highest counts are where your delivery problem already lives. You’ll usually find them before anything turns amber, and you’ll find them without a single new meeting. That’s the map you should be looking at when someone proposes the fifty-first epic.
Because a portfolio with fifty epics is fifty sources of demand moving through a network of services. The distribution matters. The contention matters. The queues matter. Starting the fifty-first changes that system.
Teams working with flow already understand this. You don’t pull work because somebody would like it started - you consider the state of the system first. Portfolio planning usually reverses that logic. We decide what we want to start, then find somewhere to put it, and capacity becomes an implementation detail. Which is how a portfolio ends up with 63 things in flight and a strategic priority list containing 41 items. All priorities, presumably. Just at different levels of priority-ness.
Turn it around. Manage the risk of active work before planning what comes next. Finish. Learn. Create capacity. Then pull.
And eventually, we arrive at the team#
After all that, the work finally reaches the delivery stage.
The team didn’t decide how many initiatives the organisation started. They didn’t choose the batch size. They didn’t design the organisational dependencies. They didn’t create the contention around the shared platform or other components. They didn’t decide to make an assumption a commitment, and they didn’t have any say in allocating capacity across the portfolio.
But when the work ages and the forecast deteriorates, that’s where we look. “Why is the team slow?”
Maybe they are. Teams can absolutely improve how they work, and some of them need to. But investigate upstream before prescribing another retrospective technique, because your delivery problem probably started long before anything entered the delivery process.
We created the traffic jam at portfolio level. Then asked the delivery teams why they were driving so slowly.
Go back to that contention report for a moment. Eight teams waiting on one component. An item open 89 days in a system that finishes 85% of its work in 23. And five green statuses, not one of which was a lie, because every initiative was fine on its own.
Here’s what changed once that map existed.
Contention became an input to prioritisation rather than something discovered three months later. When someone proposed the next thing, “where will this compete?” had an answer you could point at.
More usefully, it gave teams something to argue with. This organisation had the standard reflex when delivery slowed: add more people, spin up another team, drop it into the mix. That reflex became challengeable, because a team could now show what adding demand to a constrained component does to everything already queued behind it. Work started being routed to teams that already existed and wouldn’t deepen the queue.
And the Scrum of Scrums, that meeting everyone attends and nobody enjoys, finally had something worth looking at: a rolling six-week Monte Carlo forecast of what each team was likely to pull next, and which dependencies would come into play if they did.
Nobody appointed a queue owner. There was no new role, no new forum, no new framework. A meeting that already existed was given a real question, and the queue acquired an owner more or less by accident.
Because ownership was the thing missing all along. Initiatives have owners. Teams have owners. Components have owners. The queue that forms between them belongs to no one, so no one reports it, and no one is accountable for its existence. It grows quietly until it becomes a delivery problem and we go looking for a delivery team to explain it.
Fixing that takes one question, asked before the portfolio starts anything else.
Where is the work already waiting?
Ask it early enough, and you’ll find your delivery problem months before it ever reaches a delivery team.
