If your teams got faster with AI and leadership still can’t see the strategic work moving, this post is about why. It’s the problem I untangle with organizations at Lil Agile Monster: finding where the work is actually waiting, and building the view that tells leaders the odds their big initiatives land when they need them.
Last post I showed you a chart that tells you whether anything actually changed when you rolled out AI, and I ended on a question I didn't answer: what's actually governing how fast work leaves your system?
For a lot of you the honest answer is that work is leaving faster. Throughput went up, the chart moved, and that's real. Mine did. So here's the better question, and it's the one I actually want to answer. Why did the work speed up and the portfolio stay exactly where it was?
Here's my answer. The speed of doing went up. The speed of getting the right work to the people who'd do it didn't. The constraint didn't go away, it just relocated to a part of your system nobody was watching, because it was never the part that hurt before.
Building the thing used to be the expensive step. Everything we built to manage delivery, the boards, the columns, the WIP controls, points at that step. Now the expensive steps are getting the work ready to build and deciding whether what came back is right, and I don't know many teams whose board can even see those.
The two rates that matter
This is easier to see as two rates than as one work item, so let me put them side by side. How fast your teams finish work, and how fast work that's actually ready to start arrives in front of them. Those have always been two different numbers. They just used to move at close enough to the same speed that you only ever needed to watch one of them.
Before the agents. Your teams finished some number of work items a week. Strategic work showed up ready to start at roughly that same rate, because getting an ask ready took about as long as building the last one did. Those two rates tracked each other. There was always something worth pulling, and the fact that they were two different numbers never came up.
After the agents. Delivery went up four to five times over, which is the number I published last time. The rate at which ready strategic work arrives didn't move at all, because it never had anything to do with how fast anybody could build. It depends on other people, and on decisions that get made outside your team.
So your teams have far more capacity now than there is ready strategic work to fill it.
They don't sit and wait, and I wouldn't want them to. They pull what's available, and what's available is the small stuff, because small stuff needs very little from anybody outside the team.
That's your throughput chart. It went up, it's real, and it's made almost entirely of the work that was already easy to start, like bugs, maintenance, or pet projects not related to strategy.
That small work might be perfectly good work. The problem is that it got picked by default, to fill the space your teams now have, and nobody in the room made that trade on purpose.
Why the second rate is stuck
Getting an ask ready never got faster. Depending on the work, somebody still has to sign a contract, or release the budget, or get a decision out of a group that has its own priorities, or find the one person who knows how the current process actually works. None of it is the same list twice, and none of it is on your board.
An agent can help you draft some of that and summarize the rest, but it can't speed up a decision that belongs to somebody else. Those people aren't in your system, and nothing you did to your own delivery speed changed anything about theirs.
That work always took this long. It just was never the thing holding you up, because building took weeks, and weeks was enough room to get the next ask ready while the last one was still being built. Take the build step down to a day or two and the room is gone. The time it takes to get work ready to start isn't a preamble to your schedule anymore. It is your schedule.
Here's the part that makes it lopsided rather than just slow. That getting-ready work doesn't land on every item the same way. It lands on the work that reaches outside your team, which is most of your strategic work and almost none of your small work. So two items sit in front of the same Start line, one of them carrying weeks of getting ready and the other carrying none, and only one of them can be pulled today.
Review didn't get faster either, and it's worse than it looks. Somebody still has to read the output, understand it, and decide it's right. That person is usually not on your team. It's the customer, or somebody in the department that asked. Their capacity is fixed, it was never sized for this, and it's now sitting downstream of a build step that got several times faster. You've handed a firehose to the one part of the system that can't drink any quicker.
There's something making that worse and it's specific to AI. Agent output looks finished. A human draft signals its own roughness and you skim it accordingly, where agent output arrives polished and confident whether or not it's correct, so reviewing it properly takes more attention, not less.
And here's what makes it circular. A lot of the time the person doing that review is the same person who has to get the next thing ready. Same product owner, same subject matter expert, same contact on the customer side. So every extra item you send them to review comes out of the hours they had for getting the next ask ready, because they still only have the same amount of time to give you. Push more work through the fast part of your system and you're taking time away from the work that hasn't started yet, which is the one place you could least afford it.
This is just the constraint moving, which is the normal case
None of this is an AI phenomenon. Relieve the constraint in any system and it moves somewhere else, it doesn't disappear, and you find out where it went by measuring rather than by guessing.
What's specific to AI is how big the change was and how fast it arrived. The teams I've worked with got much faster at one part of their workflow, while the Definition of Workflow around it stayed exactly as it was. So the board is still shaped around the old constraint. The columns that get the WIP controls are the build columns. The steps where the work now actually waits, getting ready, waiting on a decision, waiting on somebody outside the team, are either one undifferentiated pile or not on the board at all.
And because they're off the board, the board can't tell you the thing you most need to know, which is that your strategic work and your small work are having completely different experiences in the same system.
That's the gap. It isn't that flow metrics stopped working. It's that they're not including your whole workflow, and they'll keep reporting reassuring numbers while the work you care about most sits still.
What to change
Five things, and they're all delivery operations policy rather than tooling.
Put the getting-ready step(s) on your board. The approval, the contract, the decision that belongs to another group, the work of figuring out what this thing actually is. Your board almost certainly has a review column already. It almost certainly doesn't have these, which is exactly why nobody can see that they've become the longest part of your delivery. You can't manage WIP or age that you can't see.
Put WIP controls on every step where work waits, and keep the ones you have on build. Build controls still matter and taking them off would flood everything downstream, so this is about adding controls where you never needed them before, not moving them. Little's Law doesn't stop applying because the work sits upstream of your Start line. Work that's partly ready and sitting still is WIP, and it slows down everything behind it the same way anything else does.
Right-size every item at the point of pull. Size your items against your SLE giving one of three answers only: it fits, it's too big so slice it, or you can't size it yet. That third answer is the one that matters now, because "can't size it yet" is real work and it needs a place to live on the board rather than a pause in somebody's head. Vague items are more dangerous than they used to be, because an agent will take a vague item and produce a large amount of confident, wrong output very quickly.
And it's fine to split an item that's already in your workflow. If something turns out bigger than you thought once it's underway, slice it where it stands. Nobody has to wait for the next pull to fix a right-sizing call that turned out wrong.
Name an owner at both ends. Somebody has to be responsible for getting the information at the front, which means chasing the approval, the decision, the answer nobody has yet. And somebody has to own saying it's done at the back, because agent output looks finished whether or not it is. Both of those are steps where the work waits on a person, and if that person isn't named the item just sits there absorbing days while everybody assumes somebody else is handling it.
Move your Start line upstream. If work spends a month getting ready and then finishes in a week, a cycle time of a week is a true number about a small slice of the work. Draw the Start line where the work actually starts, which is when somebody begins assessing it, not when a developer picks it up. You want to see the whole flow of a work item, upstream and downstream, because that's the only version of it that tells you where your delivery time really goes.
Run this on your own numbers
Start with the mix, because it's the one I'd take to your leadership. Take everything your teams finished last quarter and split it by the kind of work it was. Strategic on one side, everything else on the other. Then look at what share of that throughput was strategic.
One thing to be clear about, because it's the next place a reader's mind goes. This is a way to see what your system produced. It is not a way to treat work differently. No expedite lane, no priority swimlane, nothing jumps a queue because somebody labeled it strategic. Every item still gets pulled the same way it always did. This is just how you map your strategy onto the work your board already finished.
You might not be able to get it, and plenty of teams can't, because their work tracking isn't set up to show whether something connects to the organizational strategy or not. If that's you, stop there. Not being able to tell which of your finished work mattered to the strategy is a bigger finding than any number that mix would have given you.
If you can get it, and the count went up while the strategic share went down, that's the whole argument sitting in one number, and it's much harder to wave away than any story about queues. Your teams got faster. Your strategic delivery didn't.
Then move your Start line upstream and watch what happens to your cycle time. Redraw it at the point somebody starts assessing the work. Your cycle time will get worse, probably a lot worse, and that's the point. The time was always there. It just wasn't a part of your forecast.
You'll notice something else once you've done it. You won't need a special name for the waiting anymore, because it's just cycle time now, and your SLE is measuring the thing your customer actually experiences instead of the last leg of it.
The part I'd want you to take away
Your agents are working. That's not the interesting question anymore, and the chart from the last post will tell you either way.
The interesting question is what your system does with the time they gave you back. In the systems I've looked at, it goes into finishing more of the work that was already easy to start, while the work leadership actually cares about sits in front of the Start line waiting on a contract or information. Throughput goes up. The portfolio doesn't move. And the board says everything is fine.
Personally, I'd rather have a board that shows me the whole workflow and makes me uncomfortable than vanity metrics.
Next post: the argument that AI brings waterfall back, because now you have to know all the requirements up front. If getting work ready is the constraint, that gets it exactly backwards.
This is the second post in a series on what actually changes when AI lands in a delivery organization. The first one is AI, Kanban, and a restructure. You can prove something moved, not what moved it, and it's the one with the chart.