The Wrong Promise of Agentic Agile

There's a term gaining traction in technology circles: Agentic Agile.

The promise is appealing. AI agents take over the Agile ceremonies that no one actually enjoys — backlog grooming, sprint planning, retrospectives, status updates. Estimation becomes data-driven instead of subjective. Post-mortems write themselves from Git history and Slack threads. The two-week sprint, that ritual everyone has somehow agreed to, compresses into something closer to continuous delivery.

It sounds like progress.

I want to suggest it isn't — at least not the kind of progress its proponents think.

The substitution problem

Agentic Agile takes the ceremonies of Agile and replaces the humans inside them with AI. The standup still happens; an agent runs it. The estimation still happens; an agent does it. The retrospective still happens; an agent generates the report.

The process itself doesn't change. Only the executor does.

This is the part worth pausing on. If the process was the problem, then yes — automating it is a solution. But if the process was never the problem — if the position of process in our work was the problem — then automation doesn't fix anything. It just moves the cage to a new prison guard.

What Agile actually was

The Agile Manifesto, written in 2001, begins with this line: Individuals and interactions over processes and tools.

Read it again. Individuals over processes.

The original idea wasn't to invent a better process. It was to push back against the assumption that processes are what produce good software. The signers — all experienced developers — had seen enough waterfall methodology, enough Gantt charts, enough requirements documents that nobody read, to understand a simple thing: when you put process at the center, people stop being the center.

So they wrote a manifesto that did something unusual. It didn't propose a new process. It proposed a new priority.

Twenty-four years later, most of what calls itself Agile has reversed that priority.

How process took back the center

SAFe — Scaled Agile Framework — is the clearest example. One of its core design principles is that no single person leaving should affect the integrity of the process. Think about what that means. It means the framework is designed to make people interchangeable. The opposite of the manifesto. People are now in service of process, not the other way around.

Scrum is more nuanced. Scrum gives us useful tools: a Product Owner who represents the customer, a Scrum Master who watches over how the team works, ceremonies that create rhythm. These aren't bad in themselves. We use some of them. The trouble is what happens when a Scrum Master forgets that the role exists to serve people — when their job becomes "make sure standup happens at 9am" instead of "notice whether this team's work is flowing around people or around tickets."

The framework is the same. The orientation is different. And the orientation is everything.

Agentic Agile is the next iteration of the same mistake

When you say "let's have an AI agent run the standup, generate the retrospective, automate the estimation" — you've already agreed with the underlying assumption that standups, retrospectives, and estimation ceremonies are what produce good software. You've just decided to make them more efficient.

But ask yourself: if a Scrum Master who doesn't understand people-first is the problem, does automating their ceremonies fix anything? If a team's retrospectives have already become hollow rituals, does an AI-generated retro report make them meaningful again?

Of course not. The root cause was never execution efficiency. The root cause was orientation — what we put at the center.

Agentic Agile, in its current form, accepts process as the center and asks how to run process better. It is the same mistake SAFe made, dressed in AI.

What AI could mean if we let it

There's another way to use AI in software work — one that almost no one is talking about.

Instead of using AI to execute ceremonies, use AI to expand what one person can do.

When a developer has AI helping them write code, review code, understand documentation, explore architecture, communicate with stakeholders — that developer is no longer just a developer in the old sense. They can hold more of the work themselves. They don't need a PM to break down tickets for them, because they can break down the work. They don't need a BA to translate business requirements, because they can talk to the business directly. They don't need a QA to assure quality, because they can build quality into the code.

This isn't a claim that PMs, BAs, and QAs are bad people or that those skills don't matter. It's a claim that these roles, as separate positions, were created to compensate for a real limit: one person couldn't hold the whole context. AI changes that limit. And when the limit changes, the assumption that these roles must exist as separate positions deserves re-examination.

AI as a mirror

Here's the thing I find most interesting about this current AI wave.

It's not what AI can do. It's what AI shows us about what we were doing.

When an AI can generate a standup report, we realize the standup was supposed to be about people connecting, not about reports. When AI can run estimation, we realize the estimation ritual was always more about creating an illusion of certainty than about predicting reality. When AI can write retros, we see how often the retro was already an empty form.

AI is a mirror. It reflects which parts of our work were truly about people, and which parts were process pretending to be work.