Do We Still Need the Sprint?
What incremental delivery means, once the cost of an increment falls through the floor, whether the two-week cadence is still earning its…
Do We Still Need the Sprint?
What incremental delivery means, once the cost of an increment falls through the floor, whether the two-week cadence is still earning its keep, and what happens when every team in the building can build software.
Philly after a game.
I have sat through a few hundred sprint planning meetings. We carve the next two weeks into stories, assign owners, argue about points with the seriousness of people negotiating a treaty, and agree on a definition of done that we will quietly renegotiate by Thursday. The routine is familiar, and I have never quite believed in it. The principle under agile was always sound, almost Bayesian: ship a small increment, watch what happens, update the plan on what you learn. The process is what polluted it, the industry bolting a whole machine onto that simple idea, the certifications, the ceremonies, the two-week cadence enforced as if it were the point, the agile industrial complex that grew up around the principle and slowly buried it.
Then, last quarter, an engineer kicked off a coding agent at four o’clock on a Friday and walked back in on Monday to a pull request, a feature we had sized at two sprints of build, with review and testing on top of that, finished over the weekend while he was somewhere else entirely, sitting there waiting to be reviewed. The sprint board did not know what to do with that. We had a column of work shaped for a constraint that had quietly disappeared, and I left the meeting wondering, not for the first time, what the two weeks were actually for.
Where the two weeks came from
The sprint was an answer to a real problem. Producing a usable slice of working software used to be slow and risky, the merge alone a small adventure, and the fixed cadence existed to spread the overhead of planning, integration, review, and release across enough work to make all that ceremony worth paying for. Agile grew up in that world, a world where cutting a vertical slice of a product took days and shipping it took nerve, and the two-week box was a way to manage scarcity.
This is worth saying plainly, because the conversation about whether Agile is dead usually skips it. The cadence was never sacred. It was scaffolding around a single constraint: building was expensive and uncertain. Most of the ritual we treat as principle was really a workaround for that one fact.
What actually changed
One small, stubborn idea sits under all of it: AI replaces tasks, not engineers, and what your people spend their hours on moves, from writing code to reviewing the code that a model wrote, from building features to designing the systems a model helps build. The same shift lands on delivery. When a coding agent collapses the cost of producing an increment, the constraint the whole cadence was built around weakens, and the question stops being how to manage the scarcity of building and becomes which parts of the ritual were guarding against slow iteration, and which were guarding something else.
Some of the ceremony was guarding against slowness, the slowness of merging, the slowness of cutting a release, and those arguments are much weaker now. Some of it was guarding quality and the shared understanding of what we are building and why, and those arguments are stronger than ever, because the volume of code went up and the cost of quickly producing the wrong thing rose with it.
So the honest answer to whether the sprint is still needed is both yes and no. The sprint as a unit of work, a fixed budget for how much building fits in two weeks, matters less every month. The sprint as a unit of human alignment, a heartbeat that keeps seven people pointed the same way, matters more. The cadence survives; its job changes, from spreading the cost of building to keeping the reviewers in step.
So is Agile dead
No, though it depends on what you mean by Agile. The principle is more useful now than ever, and the apparatus the industry built around it deserved to go long before any of this. The teams declaring the whole thing dead tend to fall into the failure mode I worry about most. A roadmap goes wrong in two ways, and they do equal damage. The first is the roadmap that never changes, built in January and still marched in September after the market turned and the assumptions became obsolete. The second is the roadmap that changes every week, so responsive that it gives no direction at all, priorities lurching with each executive meeting while engineers start features they never finish. Kill the cadence entirely and you do not get freedom; you get the second failure mode wearing the costume of the first.
What I aim for instead is the shape you see every hurricane season, the forecast cone that sits tight over the storm’s current position and fans out wider the further ahead it reaches, narrow and confident up close, broad and hedged five days out. Forecasters call it the cone of uncertainty, though the useful part is the certainty at the near end. The next two weeks live there, at the tip, sharp and specific: these stories, these owners, this definition of done. The next quarter is the middle of the cone, roughly shaped, these themes, these bets. The next year is the wide mouth of it, a direction and a reason to believe in it and little more. That shape never depended on building being slow. It depends on people needing to know what is sharp and what is still a guess, a need that does not expire.
You keep the cadence and change what happens inside it. Standup stops being a check on whether the code got written, work the model now handles before you have finished your coffee, and becomes a check on whether the augmented work is any good and whether we still agree on what we are building. The increment shrinks and ships more often, continuous delivery arriving less as a methodology you adopt than as the natural consequence of a cheap increment. The discipline that mattered, estimating build effort, gives way to two that matter more: defining done well, and reviewing fast. The ritual you protect is no longer planning but review.
That holds for now, at least, because I do not think review is where this stops, either. The same force that collapsed the cost of writing the code is already coming for the cost of checking it, and I expect review to give way much as the build did, sooner than most teams expect. That is a longer argument, and one I will make soon, in a piece of its own. For time being, review is still where the human hours go, and building the cadence around it is the right call.
The part most teams are not ready for
The same force reshaping your sprint, the collapse in the cost of building, does not stay inside the engineering org; it leaks out into every team that ever wanted software and waited in a queue for it.
Non-technical teams have always built software. They just called it spreadsheets. Every finance department I have worked near ran on a load-bearing Excel workbook, thousands of rows deep, threaded with VBA macros written years ago by someone who has since left, understood by no one, and trusted absolutely by everyone. The phenomenon has a name when it goes wrong, shadow IT, and a long history of going wrong in expensive and quiet ways: the workbook that silently rounds the wrong number for a year, the macro that breaks the morning its author is on a plane, the report the whole department leans on and no one left can rebuild.
Now put AI on top of that history. The analyst who used to write a macro does not write a macro anymore. She describes what she wants to a coding agent and gets back a real application, a database behind it, a web front end on top, something that looks and behaves like software her IT department would have spent a quarter building. Gartner’s projection for this year puts roughly three-quarters of new applications on low-code and no-code tools, with eighty percent of the people using them coming from outside IT, and citizen developers outnumbering professional developers at large enterprises by something like four to one. The capability is real and useful, closing the gap between the people who feel a problem and the people who can build for it, and it is dangerous in the exact ways the spreadsheet already taught us.
The failure modes do not improve when the medium moves from a macro to a real application; they get worse, the stakes higher and what breaks harder to read. No version control. No review. No owner once the author changes teams. A security hole nobody audited. A real business process running on an application that one person understood and that person just left. We are about to relive the whole shadow-IT story at higher resolution, and the organizations that come through it well will be the ones that put governance in front of enablement rather than bolting it on after the first one catches fire.
What this does to the manager’s job
The role shifts from gatekeeper of building to steward of what happens after the build, and a couple of values suddenly carry most of the weight.
Ownership comes first. When your team ships code a model wrote, they have to own it as fully as if they had typed every line, and the same has to hold for the analyst who shipped an application she does not think of as software. Someone owns it, owns it when it breaks at two in the morning, owns the call to retire it when it has stopped earning its place. An unowned application is a liability with a countdown on it.
Craft comes next. Anyone can ship AI output fast, and once everyone can, speed alone stops being worth much. What matters is whether the work is also good: reviewed, understood, something the next person can maintain. The teams that win are the ones who manage both.
The durable artifact, meanwhile, stops being the code. When anyone can generate an implementation in an afternoon, the implementation is the cheap part, and the requirement, written down clearly enough that a person or a model can build against it and a reviewer can judge the result, becomes what lasts. The spec outlives the code that satisfies it. That is a comfortable idea for an engineering team and an uncomfortable one for a finance department that has never written a requirement in its life, which is exactly where your attention now has to reach, past the edge of the engineering org and into the cross-functional teams forming everywhere else, business people and engineers building side by side.
Monday morning
Enough framing. Here is what I would actually do.
Stop sizing work by build effort, and start sizing it by review and integration risk, because building is no longer the expensive part, and a board that pretends otherwise is a board that lies to you.
Shrink the increment and ship it more often, daily where you can, keeping the cadence as a heartbeat for alignment rather than a budget for how much code fits in a fortnight.
Make review the ritual you protect, the way you once protected planning, with a real bar for AI-generated work, a clear flag in the pull request, and a team-level policy you wrote yourselves rather than one handed down by a corporate committee.
Find the shadow software already running in your building, the spreadsheets, the scripts, the workbook finance will not let you touch, and decide deliberately what gets owned, reviewed, and supported, and what gets retired before it becomes the next late-night incident.
Write down what done means now that done has to include a person understood this and a person owns it, because that clause is the whole job, and it is the one part of delivery that did not get cheaper.
The cadence will keep changing
The two weeks were never the point. They were a workaround for a cost that has now fallen, and clinging to the workaround after the cost is gone is how good practice hardens into theater. Keep the part of the cadence that keeps people aligned, drop the part that only ever managed the scarcity of building, and turn to the harder problem, the permanent one, waiting on the far side of every increment a model can now produce over a weekend with no one watching.
In a building where anyone can build anything, someone still has to care whether it is any good, own it when it breaks, and decide what deserves to exist at all. The frameworks will keep shifting under us, sprint giving way to flow, flow to whatever comes after it. The need for a person at the center of it, accountable for the result, will not shift. That part was never going to automate, and it is, as it always was, the work.
By Joshua McDonald on June 28, 2026.
Exported from Medium on August 26, 2026.
Reader discussion