Soundings
Our Perspectives and Insights
Your Sprint Didn't Get Faster. Your Batches Got Bigger.
I want to share a thought exercise I started on agile combined with AI. Take a working system, move exactly one lever, hold everything else still, and follow the consequences honestly to the end. No villains, no discipline problem, just arithmetic.
The system is a two-week sprint. The lever is how fast the development team can build. Push it hard: what used to take a week now takes an afternoon with AI-enabled engineers. Nothing else about the organization changes. Same planning meeting, same stakeholders, same review, same retro, same calendar.
I’ve led teams that pulled in more than they planned (the goal of agile), and it was a great outcome to have. But where do negative effects start to appear?
Agile Won on Two Things
Strip away twenty-five years of ceremony arguments and Agile beat waterfall on two counts.
The first is cycle time. An eighteen-month program where you learn you were wrong at the end becomes a two-week loop where you find out on the fourteenth day. You see it, you correct, you go again.
The second is subtler and it is the one that matters here. Agile made work get pulled instead of pushed. Capacity draws the work in rather than a plan shoving it down. That has always been the friction point with organizations, because organizations want to push. Push is how budgets are built, how commitments are made, how a date gets promised to a board. Every Agile transformation I have watched fought that same fight, and the teams that actually got the benefit were the ones that held the pull line.
Push is how budgets are built, how commitments are made, how a date gets promised to a board.
Now Hit the Accelerator on the Pull Lever
The team finishes the sprint in two days. Everybody is pleased. What happens at the next planning meeting?
They pull more in. Of course they do. There is capacity sitting there and a backlog sitting there, and pulling more in is the correct behavior for a pull system. Nobody in that room is doing anything wrong.
Follow it. More items come into the sprint. Which means more development work lands per planning session, per backlog refinement, per showcase. Measure the sprint in units of development rather than in days on a calendar, and the sprint just got longer. Do it again next time and it gets longer still. The calendar says two weeks the entire way through.
Keep going to the end of the line and you arrive somewhere familiar. A large batch of work, specified up front, built without interruption, reviewed once at the end, in front of stakeholders who have not seen it in a long time measured in the only unit that matters, which is how much changed since they last looked.
That is waterfall. The team has gone faster and gone back to 2003 at the same time.
The calendar says two weeks the entire way through.
This Is Arithmetic, Not a Discipline Problem
Sprint length was originally set by how much a team could build. But for at least the last decade, organizations set it by the fixed overhead of running the ceremony: planning, review, retro, and above all getting the right people in a room at the same time. That overhead is why sprints land at one to four weeks and stayed there.
Donald Reinertsen’s work on product development flow makes the mechanism explicit. Optimal batch size sits where two costs meet. Holding cost is what it costs you to have finished work sitting undelivered. Transaction cost is the fixed overhead of pushing a batch through. Move either one and the optimal batch moves with it.
AI drove holding cost toward zero. Transaction cost did not move at all. Coordination, review, and stakeholder attention cost exactly what they cost in 2019. When one of the two costs collapses and the other does not, the arithmetic does not suggest a bigger batch. It requires one.
So the team pulling two months of stories into a two-week sprint is not undisciplined. They are solving the equation in front of them correctly. You cannot fix that with a retro.
The arithmetic does not suggest a bigger batch. It requires one.
The Pull System Survived. Its Bottleneck Moved.
So now the next level of the thought exercise.
Pull did not die. The pull signal used to be developer availability: work entered when somebody was free to build it. That signal is now nearly free, so it stopped being the constraint. What replaced it is reviewer attention.
That is a different resource with genuinely different properties. It does not scale by hiring junior talent, because reviewing well requires more context than building does. It degrades with volume instead of staying flat, because the tenth review of the day is not the quality of the first. And unlike developer hours, almost nobody measures it. Teams that have run into this have landed on the same crude answer: cap what the agents produce to what humans can actually review.
The numbers line up with the story. Faros AI’s 2026 telemetry, two years of it across twenty-two thousand developers, has AI increasing pull request size by 51%. DORA’s standing finding is that working in small batches is what amplifies AI’s positive effect on delivery. Read those two together and the trap is plain: the practice that makes AI pay off is the exact practice that AI adoption erodes.
The same data set has the constraint failing out loud. Pull requests merging with no review at all, human or agentic, are up 31.3%, and Faros reads the cause the way I do: reviewers cannot keep pace with the volume arriving for their attention. Median time in review is up 441.5%. That is not a team getting sloppy. That is a queue overflowing.
Temporal’s 2026 State of Development report, fieldwork run April and May of 2026, has 80.8% of engineers using AI agents daily or more, against 47.3% a year earlier, and 51.3% going from prototype to production-ready code in hours or less. Treat that adoption number as a floor rather than a headline, since the fieldwork is several months old and this curve has not been flat.
And the honest counterweight, also from DORA, which I want in here because it keeps this from being a tools-fix-it article: AI amplifies team dysfunction about as reliably as it amplifies capability. A team that was not reading its work carefully before is now not reading much more of it.
The practice that makes AI pay off is the exact practice that AI adoption erodes.
Lean Solved This Problem Already
We can pull lessons learned by Manufacturing forty years ago. Plants did not get to small production lots by telling people to run small lots. Small lots were uneconomic, and everyone on the floor knew it, because every changeover meant tearing down a machine setup and building a new one. Hours of it. With a setup that expensive, big lots were correct. So how do you make small lots at speed?
What actually worked was attacking the changeover itself. Single-minute exchange of die: get the setup from hours to minutes, and small lots stop being a sacrifice and start being obviously cheaper. Batch size was never the thing to manage. It is a derived quantity. It falls out of setup cost, and it moves when setup cost moves.
AI slashed the machining time and left the changeover exactly where it was.
The Answer Is More Touch Points, Not More Ceremonies
Martin Fowler has a line: “if it hurts, do it more often.” His point is that for a lot of activities the pain grows exponentially with the time length between them, so integrating daily hurts far less than integrating quarterly. Increased frequency is the cure.
Which sounds like advice to hold more meetings, and it is not. That is the trap, and it is why so many teams answered this by shortening the sprint and got a worse overhead ratio for their trouble. If the ceremony is expensive and you run it twice as often, you have doubled a cost you never measured.
What Agile was actually reaching for underneath all the ceremony was frequent, high-level check and adjust. Not more process. More moments where somebody looks at where this is going and says yes or says stop. The ceremony was one delivery mechanism for that, built when getting people in a room was expensive. The goal was never the meeting.
Four Moves for a Delivery Leader
- Separate the two jobs the sprint is doing. One is governance: stakeholders, budget, the board conversation. The other is build and verify. Stop making one event serve both.
- Compute your transaction cost. Hours per person per sprint spent on ceremony and on getting stakeholders aligned. Most organizations have never measured it.
- Size the pull signal you actually have. Reviewable units per week, not developer headcount. If nobody owns that number, your batch size is being set by accident.
- Make a look cheap, then look constantly. The setup cost worth attacking is the cost of getting a look at the work. If a look means scheduling a meeting, preparing a demo and assembling stakeholders, you will ration looks, and rationed looks are what make the batch big. Cheap looks are concrete: the product owner engaged live and daily instead of at the sprint boundary, seeing working software as it appears rather than a demo assembled for a showcase, with acceptance agreed before the work starts so a review confirms instead of discovers.
That last one is what Fowler’s line actually asks of you. Not do the painful thing more often through sheer will. Make it cheap enough that often is possible.
The Bottom Line: Speed Was Never the Scarce Part
Every organization I have worked with wanted the development team to go faster, and most of them got their wish this year. Almost none of them changed anything about what happens after the code exists, which is where the whole rest of the system lives.
The sprint will survive this, by the way, and not for the reason its defenders give. It survives because it was quietly load-bearing for things that have nothing to do with software: the stakeholder rhythm, the capacity plan, the budget cycle, the monthly conversation with the board. None of that got faster. Teams are keeping the container because the container was never really about the code.
Just do not mistake keeping the container for keeping the benefit.
AI does not reward the organizations that build faster. It rewards the ones that can still read and adjust what gets built.
A Pilot & Rutter principle.