Komforan
DA
All posts

Agile solved a bottleneck that no longer exists

· Henning Kjær

It is worth remembering what Agile was actually a response to.

Not to waterfall as an aesthetic failure. To a constraint: implementation was slow, expensive and hard to reverse. Building the wrong thing cost you months, so everything else in the process was arranged around not doing that. Small batches, so a wrong turn was cheap. Short feedback loops, so you found out early. Deferred commitment, so you decided as late as responsibly possible. And a whole readiness machine — refinement, estimation, acceptance criteria, definition of ready - whose real job was to keep an expensive, scarce resource fed with work well enough understood to be built.

A sprint is a batching mechanism. Its length was chosen against the cost of building.

Two years ago, if you looked at the timeline of a feature from idea to production, the longest single stretch was implementation. Every ceremony we run was designed around that fact.

The constraint moved

It is not there anymore. Not on most work, anyway.

Anthropic put it about as plainly as a vendor can in their AI-native SDLC playbook: code is no longer the bottleneck, and the constraint moves to the steps on either side of the build phase - plan, review and test, deploy - which still run at human speed. Their own engineering organisation reports Claude authoring around 80% of merged code, with engineers shipping roughly eight times as much code per quarter as they did a few years ago.

Take that seriously for a moment and the consequence is uncomfortable. If you speed up the build phase and leave everything else the same, you do not get a faster team. You get a queue. The work piles up in front of review, QA, security and deployment, and the team's throughput is exactly what it was before - just with more anxiety and a larger inventory of half-finished changes.

Two bottlenecks, and only one of them is interesting

The first is mechanical: review, testing, security scanning, approvals, deployment. This is the one everyone notices first, because it hurts immediately. DORA has been describing it as downstream disorder - individual productivity gains being swallowed by the pipeline they flow into.

It is real, and it is a solved problem in the sense that we know what the solution looks like: platform engineering, automated gates, small batches, paved roads. Unglamorous, well-understood, mostly a question of whether anyone is funded to do it.

The second one is the interesting one, and it does not go away with better tooling: deciding what to build.

When implementation was expensive, direction-setting was cheap by comparison. You could spend a week arguing about scope and it barely registered against three months of building. That ratio has inverted. When the build takes two days, a week of indecision is no longer a rounding error - it is the project.

And it is not only about speed. When building was expensive, being wrong was expensive, so we invested heavily in not being wrong - analysis, discovery, business cases. Now that building is cheap, being wrong is cheap too. That should change how we decide, not just how fast.

What this actually changes

  • Refinement flips purpose. It used to exist to make work implementable. Implementable is now nearly free. Refinement now has to earn its place by answering a harder question: is this worth building at all, and how will we know if it worked?
  • Estimation loses most of its value. Story points were a proxy for implementation cost, at a time when implementation cost dominated. Estimating the cheap part while the expensive part - the decision - goes unexamined is measuring the wrong thing carefully.
  • The spec becomes the primary artifact. Not the ticket. Anthropic's playbook makes this concrete with an artifact chain - intent, then spec, then plan, each version-controlled and readable by both humans and agents. Whatever you call it, the thing you write before building now determines the output far more than it used to, because something else is doing the interpreting.
  • Prototypes beat analysis more often than they used to. If you can build three versions in the time it takes to hold two meetings about which one to build, the meetings are the expensive option. Building becomes a research method, not just a delivery activity.
  • Reviewing goes up in value; writing goes down. The scarce skill is judgement about what came out, not speed at producing it.
  • Product ownership becomes the constraint. This is the part I find genuinely hard as a product owner, software architect and technical lead: when the team can build almost as fast as I can decide, my indecision is the team's idle time. That is a new and quite exposing position to be in.

What has not changed

Almost none of the actual Agile principles. Short feedback loops, small batches, working software over documentation, responding to change - all of that is more true now, not less. DORA's finding that AI amplifies whatever a team already has cuts both ways: a team with weak feedback loops now gets to be wrong faster and at greater volume.

What has expired is the machinery we built around a constraint that has moved. The two-week batch. The estimation ritual. The refinement pipeline whose purpose was keeping developers fed. Those were never the point - they were the local solution to a specific bottleneck, and we mistook them for the method.

One honest caveat: the most confident claims here come from companies selling AI tools, mine included in spirit. The productivity gains are genuinely uneven - substantial on greenfield work, much thinner on large legacy systems, and in some measured cases negative for experienced developers on complex mature codebases. "Code is no longer the bottleneck" is true of a lot of work. It is not yet true of all of it, and knowing which kind you are doing is its own skill.

Doing what Agile did

The Agile Manifesto was written by people looking clearly at where the actual cost of software was and designing around it. The most Agile thing available to us now is not to keep running the ceremonies they arrived at. It is to do what they did: look honestly at where the cost has gone, and rebuild the process around that.

The cost has gone to deciding. It would be strange to keep optimizing the part that got cheap.

Sources