Agile Died Again?

I know I know...here we go again, but it is apparent this is still a great topic to debate and learn how to get more articulate, so here's my try (again); more feedback can't hurt :)

I keep hearing that my old friend Agile is dead. And yet… I still see them everywhere I go.

So which is it? Maybe, to entertain the debate, I’ll concede that "Agile" is dead: the spirit of Agile is still very much alive.

Agile has been with me since the start of my tech journey back in 2004. By 2014, I had built an entire business around it (this one). Agile has been one of my most trusted companions. So yeah, hearing people say it’s gone stings a little. Rather than argue, maybe I’ll agree:

Agile, as a name, a brand, or a thing… might be dead to some.

But its essence? That lives on. I’ll keep honoring the pioneers of the late ’80s and ’90s who gave birth to what was once called “lightweight methods.” Maybe letting go of the name Agile will give its spirit more room to thrive and make it more powerful.

Because, like anyone, we’ve truly loved and lost, sometimes, we still feel them with us. And we carry them forward.

What I really think is “Agile isn’t dead; it won.”

That was my takeaway from a recent post. It’s not that we stopped doing Agile (whatever that means), it’s that we do it so well now that it’s invisible. It’s become the norm, the default.

Bogdan Chayka responded with an interesting perspective on a thread in LinkedIn (thanks, Bogdan):

“Now we don’t even need processes to deliver a product. In the morning, we talk about it, and it’s done by the end of the day. AI is removing dependencies. No need for long sprints or department handoffs. One person can go full-stack and ship independently. That’s closer to Agile than what we used to have.”

And hey, there’s truth in the claim that AI is removing friction. Full-stack devs can move fast. However, we still need to discuss the why behind Agile.

Flashback to the 1960s Software Crisis

Back then, we realized that software development wasn’t like building cars. It wasn’t predictable, repeatable, or neatly defined. Every piece of software was a new problem. Winston Royce tried to articulate this, but most misread his paper and invented Waterfall—a method he actually warned against.

The real lesson?

Software is knowledge work.

Not manufacturing. Knowledge work needs iteration, feedback, and adaptation. There's not one single approach; we are all limited by our own skills, abilities, and experiences. Technology requires multiple skills to solve the problem. How can we know it all? We can’t.

We are also limited (usually) in the actual domain of the business process problems we are trying to solve. How many software coders fully understand the finance and accounting processes they are automating? We rely on other humans to describe that process (the requirements), and that's a whole other post!

But early on, we didn’t have the tools to work with fast feedback and testing. Mainframes, punch cards, shared systems... just testing code was a bottleneck on the mainframe (think about having to schedule a run of your new code you created over the last 5 hours, only to find out they can't run it until tomorrow). Planning up front was survival.

Then the Tech Caught Up

By the late '80s and early '90s, developers had their own machines. Prototyping became real. Testing was quicker. Practices like Scrum, XP, and DSDM emerged. The Agile Manifesto followed in 2001, not as a process but as a shared set of values and principles for navigating uncertainty.

Agile Was Always About Adapting to Complexity

Today, with AI accelerating everything, we’re seeing another leap. But faster tooling doesn’t remove the need for discipline. In fact…

We Still Need Sprints and Timeboxes (I think)

Just because some tasks can be completed in a day doesn’t mean everything can. Some work simply takes longer to deliver real value (which is different than just being usable for feedback).

Sprints still matter. They help us:

• Estimate cost and complexity—critical for business prioritization
• Break down and plan work meaningfully
• Provide a steady cadence of feedback and reflection
• Anchor coordination across teams

Even in a world of AI superpowers, timeboxing still matters. We don’t get rid of the 24-hour day just because some tasks don’t need all 24 hours. Sprints, like calendars, help us align and plan together.

So no, I don’t buy that we’ll get so fast we won’t need sprints. I still find them incredibly valuable, especially for feedback, focus, and flow.

The Agile Future = Tech + Principles

We’ve always been limited by the technology of the moment; that ceiling is rising faster than ever. AI is accelerating what Agile teams can achieve, yet it doesn’t replace the principles that brought us this far.

The business still expects us to drive fast… even in the fog. Agile is how we do that: we focus, adapt, and keep moving. (Think about it: what do you really do when you’re asked to speed up in foggy conditions? You sharpen your focus, reduce distractions, and stay deliberate.)

Scrum is one powerful pattern for working this way. It’s not the only approach but a proven and widely adopted one. Other patterns will come as well. But agile? It stays.

Call it whatever you want, but some people still need to learn how to work this way. So I’ll keep teaching it. Because Agile hasn’t died, it’s evolved.

And whether you think it’s dead or alive… it already won.

“Agile isn’t dead: it won.”