Lately, in almost every conversation I have about software delivery, the same sentence comes up: "AI will kill Scrum."
I hear it from developers I respect, from consultants who have spent decades inside transformation programs, from executives sketching out their next operating model. At first, I nodded along. The argument is hard to dismiss.
After all, AI already writes code, drafts tests, summarizes meetings, analyzes tickets, maintains backlogs, and quietly coordinates work between tools that used to require entire teams to keep in sync. If a machine can do all of that, then the rituals we built around uncertainty — standups, sprint planning, story points, retros — start to look like wooden scaffolding around a building that no longer needs scaffolding.
But after years working inside large enterprise transformations — SAP programs, cross-functional teams scattered across countries and time zones, organizations on their third or fourth attempt at "being Agile" — I have come to a different conclusion.
I do not believe AI will eliminate Agile organizations.
I believe AI will finally force them to become Agile in the way they always claimed to be: at the level of the business, not just at the level of the development team.
What Scrum was actually for
Most discussions about Scrum get stuck in the texture of it. Standups. Sprint planning. Velocity. Jira boards. Burn-down charts. We argue about ceremonies as if Scrum were a method for running meetings.
It was never really that.
Scrum exists because uncertainty exists. It is a way of working that assumes you do not fully know what you are building, that priorities will shift, that information is incomplete, that the technology itself is moving underneath you. If a project were fully predictable — if you could specify everything up front and trust that nothing would change — Scrum would not just be unnecessary, it would be expensive overkill. A traditional sequential approach would cost less and feel calmer.
The reason Scrum is expensive is precisely because it accepts that uncertainty has a price, and tries to pay it in small, frequent installments rather than in one catastrophic correction at the end. It demands skilled people, constant communication, fast feedback, and the willingness to reprioritize without taking it personally. That is real organizational overhead. But the cost of building the wrong thing for twelve months is much, much higher.
The version most of us actually lived
The problem is that very few organizations ever implemented that Scrum.
What most of us experienced was a bureaucratic version — Scrum reshaped into something the existing organization could swallow without changing too much. Over time, the Scrum Master role drifted into status collection, Jira administration, and meeting coordination. Daily standups became long, careful walks through a board, presented upward as proof of progress. Retros became ceremonial. Estimates became commitments. Backlogs became to-do lists with extra steps.
I have sat through more of these meetings than I would like to admit, and I think this is the real reason so many professionals are tired of Agile. They are not tired of the principles. They are tired of attending a daily fifty-minute meeting that does not actually help them deliver anything.
A real Scrum Master is not primarily a status collector. A real Scrum Master helps people work together — removes blockers that the team cannot remove themselves, protects psychological safety, makes difficult conversations possible, notices the team dynamics that are quietly breaking and helps repair them before they show up in delivery.
It is worth noticing that these are exactly the things AI still cannot do.
AI can automate reporting. It can summarize a ticket. It can read a velocity chart. But trust, motivation, fear, organizational politics, and the small human signals that tell you a team is in trouble before any metric does — these remain stubbornly, almost reassuringly, human.
What AI actually changes
What AI changes is not the need for coordination. It changes where coordination is most expensive.
For most of the history of software, the bottleneck was implementation. Writing code was slow, expensive, and risky. Agile methodologies grew up around that constraint, because optimizing the bottleneck is what every sensible methodology does.
AI is dissolving that bottleneck — not entirely, not yet, but visibly. Prototypes appear in hours. Boilerplate disappears. Documentation gets written almost as a side effect. The marginal cost of "trying something" drops, and the work moves upward in the stack.
When execution becomes cheap, the constraint moves to everything before execution: prioritization, decision-making, architecture, evaluation, governance, alignment with what the business is actually trying to do. The question quietly shifts from "Can we build it?" to "Are we sure this is the right thing to build?"
That is a much harder question, and it lives much further up in the organization.
From team alignment to business alignment
If implementation effort genuinely shrinks, the energy organizations once spent coordinating tasks will need to be spent coordinating value.
This is why I think the conversation is moving from team-level ceremonies to business-level synchronization. In large enterprises, we already see it in mechanisms like PI Planning, release train coordination, portfolio prioritization, architecture governance — the messy, slow work of getting many groups to agree on what matters this quarter and why.
These mechanisms used to feel heavy and almost embarrassing compared to the elegance of a well-run sprint. I suspect they are about to feel essential.
What may also change is the shape of the teams themselves. Instead of large development organizations of a hundred or a hundred and fifty people, I expect to see smaller, more senior, more genuinely cross-functional groups — people who can hold business context, technical architecture, product vision, and organizational politics in their heads at the same time, and translate fluently between them.
AI amplifies leverage. Fewer people will be needed for repetitive implementation. More people will be needed to answer the harder questions: What does "good" actually mean here? Who is this for? What problem are we really solving? What are we choosing not to do?
Those are not engineering questions. They are business and human questions.
AI does not remove complexity. It moves it.
There is a tempting story in which AI quietly removes complexity from organizations. I do not believe that story.
In practice, the more AI you build into a system, the more you need around it: high-quality specifications, careful evaluation frameworks, clear definitions of success, governance that catches drift, architecture discipline that prevents the whole thing from quietly degrading into noise. Good AI systems demand good evals — and good evals demand people who deeply understand the domain.
So the future organization, in my view, is not less reliant on expertise. It is more reliant on it, just differently. It will need domain experts who can define what a correct answer looks like. It will need product owners who can translate ambiguous business goals into something a system — human or AI — can actually deliver against. It will need cross-functional people who can see the whole picture, not just their part of it.
AI can accelerate delivery enormously. But someone still has to decide what "good" means. That is, and will remain, a human responsibility.
What I think actually comes next
I do not think the future belongs to organizations with the most polished Agile rituals.
I also do not think it belongs to fully autonomous AI systems running without human coordination — at least not for the kind of work I see in enterprise transformations, where the cost of being wrong is measured in years and millions, and where most of the difficulty has never been technical.
The future, I suspect, belongs to organizations that are simply faster — faster to decide, faster to align, faster to change direction when reality changes. Fewer ceremonies. More AI-assisted execution. Smaller, more senior teams. Shorter business cycles. Stronger strategic alignment between what the company says it values and what it actually funds.
Some Agile practices will quietly disappear, and very few people will mourn them. Much of the administrative work currently done by Scrum Masters, project managers, analysts, and developers will be absorbed by tools. None of that means Agile is dying.
Because uncertainty is not going anywhere. Priorities will still shift. Strategies will still change. Markets will still surprise everyone. Architectures will still need governance, and people will still need to look at each other and decide, together, what matters this week.
If anything, AI will force organizations to become more adaptive, more responsive, and more honest about what they are actually trying to do than they have ever been.
The future is not the death of Agile.
It is the long-overdue transition from development-centered Agile to business-centered agility.
And I think that, in the end, may turn out to be the most important Agile transformation any of us has lived through.