🪓 It's Time to Kill Agile (for Most Use Cases)

I've been an Agile evangelist and a Scrum team member — if you will — on many projects and in many organizations over the years. I've stood on both sides of the aisle, or maybe more accurately, both sides of the stand-up circle.

I've been the developer just wanting to get to work, quietly hoping that the promise of fewer meetings and fewer artifacts would one day come true. And I've been the Project Manager and Scrum Master, hoping the developers might show just a little more flexibility — maybe include an estimate (even a wild guess), or at least show up on time for stand-up.

What I know is that the reaction to waterfall and big-up-front design was absolutely correct in most cases. Agile, in all its flavors and customizations, helped bring countless projects back to life and get delivered on time. But it didn't solve every problem, and it created plenty of new ones — with its own detractors and dysfunctions that still linger today.

And now, I believe it's time — in most cases — for Agile to die. Some teams have already taken the axe to it. Others are trimming carefully with scalpels. Many are searching for alternatives in Lean, Six Sigma, or new home-grown versions of Agile — and that's fine. In fact, that's exactly in the spirit of the original manifesto.

As the 12th Principle of the Agile Manifesto reminds us:

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

For many of us now working with AI, aggressive CI/CD, or even older component-driven architectures, the pace of real work has outgrown Agile's cycles and ceremonies. We've hit that regular interval again — and it's time to tune and adjust. In other words: it's time to kill Agile, or at least start hacking away until there's almost nothing left.

After two decades helping teams find the balance between structure and flow, I've watched Agile grow from revolutionary to routine — and now, to restrictive. At Buildly and inside Buildly Labs, we've spent the last few years stripping back what doesn't serve us anymore.

What's left we call the Radical Process, an evolution of the ideas I first explored in Radical Therapy for Software Teams. It's still rooted in trust, collaboration, and reflection — but now it's enhanced with automation, AI, and a deep understanding of how modern remote and hybrid teams actually work.

This isn't an anti-Agile rant. It's the natural continuation of what the manifesto asked us to do: reflect, adapt, and evolve.

At Buildly, we didn't throw Agile out overnight. We just started trimming. Meetings that produced no new insight were cut. Ceremonies that slowed real work were automated or absorbed into daily flow. And the result was a process that moves as fast as the teams — and the tools — driving it.

The tipping point came when we realized most sprint cycles were already outdated the moment they started. By the time a story moved from grooming to development, an AI-assisted prototype was often already in place.

So we experimented with what we now call Radical Intervals — micro-loops of continuous planning and delivery. AI monitors code activity, meetings, and issue threads, surfacing new features or blockers automatically. Teams can react and deploy in real time, without waiting for a new sprint to start.

Retrospectives still happen — but asynchronously, inside the workflow. AI summarizes what's working, what's slowing teams down, and even recommends changes. The outcome is a self-correcting process — one that adapts itself, rather than waiting for a manager to call a meeting.

It's not Agile. It's not Lean. It's something leaner still: Radical.

As Dave Thomas, one of the original signatories of the Agile Manifesto, wrote over a decade ago:

"Once you put a capital A in Agile, it stops being agile."

That line has aged like fine wine. What began as a movement of freedom became a bureaucracy of certifications and checklists. Even mainstream business writers agree:

• • Harvard Business Review asked whether we've pushed Agile beyond its usefulness.
• • TechBeacon declared "The End of Agile."
• • TDAN cataloged its critics.

All point to the same truth: the framework that once freed us now often slows us down.

Agile isn't the enemy. It was a necessary correction to the rigidity of waterfall. But software development has changed again. AI, automation, and continuous deployment have permanently altered the rhythm of building. We can't afford processes designed for slower, more predictable cycles.

The Radical Process is simply the next reflection — the next adjustment — in the spirit of that 12th principle. It's about cutting back to what really matters: communication, clarity, and constant adaptation. It's about letting automation handle the repetition, so humans can focus on creation.

If Agile helped us crawl out of waterfall, maybe Radical will finally let us stand upright again.