Why Scrum is reaching its real end in the age of AI

Scrum was never invented because small steps are beautiful.

It was invented because people cannot coordinate fast enough. Sprints, standups, story points, retros — that is almost entirely machinery against a single problem: limited communication bandwidth between humans. Anyone who has worked in a team of eight knows the pattern: the number of coordination paths does not grow with the size of the team, it grows faster. Each additional person means not one additional connection but several. Scrum is a very carefully considered answer to exactly that growth.

Now comes the part few people say out loud: this problem is disappearing, to the extent that a growing share of the implementation is taken over by AI agents. A dialogue between two AI instances needs no sprint boundary. No capacity estimate. No standup to work out who is doing what. The communication bandwidth that was the real bottleneck among humans is simply no longer a bottleneck for AI agents.

Two problems that were never cleanly separated

So is Scrum dead? No — and this is exactly where it gets interesting if you look more closely.

Scrum solved two completely different problems at once, and in practice they were almost never considered separately:

First: coordination between people. How do you align several people so that their individual results fit together in the end? That is the problem that is disappearing.

Second: uncertainty about the real requirements. Do you know at the start of a project what will actually be needed at the end — or does that only emerge in contact with real users, real data, real conditions? That is a problem that stays exactly the same size no matter how much AI is involved in the development process. No system, however fast, knows by itself what a user actually needs when even the user cannot say it precisely yet.

This conflation is why the debate about Scrum so often runs in the wrong direction. Whoever says "Scrum is obsolete" usually means the first problem. Whoever counters "but we still need short feedback cycles" usually means the second. Both are right — they are simply talking about two different things as if they were one.

The example that opened my eyes

I saw this in a very concrete case that cannot be argued away: a data model that has to stay consistent across several features.

A data model cannot be cleanly cut into independent sprint slices. Every team, every sprint, every story models "its" slice of reality — and at the seams between those slices, contradictions arise that often only become visible late, when two features that were built independently meet. This is not a detail that more discipline would fix. It is a structural consequence of how Scrum divides up work in the first place, in order to make coordination between people manageable. Conway's Law says hello: the architecture of a system almost inevitably follows the communication structure of the organisation that builds it. A team organised into sprint slices tends to produce an architecture that falls apart into slices too — even when the domain itself does not support that division.

Waterfall had the same underlying problem, only with the sign reversed: a principle that is reasonable in itself — think carefully before you build — but without any mechanism for keeping a growing body of requirements free of contradictions over time. Revisions became more expensive the longer an error stayed undiscovered, and at some point it was cheaper to keep quiet about a mistake than to admit it.

Three axes instead of a matter of faith

The real question for 2026 is therefore not "Scrum or Waterfall", as if you had to pick a camp. Every method can instead be measured along three independent dimensions:

How expensive is coordination between the people involved? How much prior knowledge about the actual requirements is available or reachable at all? And how expensive is it to keep a growing body of decisions consistent while it changes over time?

Historically the first and the third were tightly linked — because the same person responsible for coordination was also responsible for checking consistency, with the same capacity limits. That was never a law of nature, only a consequence of the tools available. That coupling is precisely what is coming undone. What this means for the second dimension — the uncertainty about real requirements, which persists no matter how fast and cheap everything else becomes — is the subject of the next article in this series.

What follows in practice

For an existing Scrum team this does not mean breaking with its own self-understanding. It means a shift in what the iterative cycles are actually still needed for. The ceremonies meant to solve pure human coordination lose weight as a growing share of the implementation moves to AI orchestration — there is simply less to coordinate there, because a synthesised, consistent plan has already settled the seams. The short feedback cycles themselves remain as important as before, but they move to where the uncertainty actually is: into the dialogue with the decision-maker and into real contact with users — not into coordination between developers who no longer have that problem.

This is exactly what I have been working on for eight months, in a very practical way, on a software project of my own that proves its own methodology on itself. The next article is about SAFe — and why it answers a coordination problem with even more coordination instead of reducing the need for it.