I keep hearing that Agile is dead. Honestly, I’ve been hearing this for years, and lately, it seems louder than ever. But I have to disagree—and not just because I’m an Agile practitioner.
You might think, “Of course, you’re going to say that. You’ve been in this game for 15 years.” And yes, Agile has been a cornerstone of my work for well over a decade. But this isn’t about blind loyalty. It’s about a fundamental misunderstanding of what Agile is supposed to be. The problem isn’t with Agile itself—it’s with how it’s often practiced and implemented.
For me, Agile has always been about flexibility, empowerment, and adaptation. I’ve worked with all sorts of frameworks—Scrum, Kanban, Scrumban, Lean, Extreme Programming, and more. But here’s the thing: I’ve never used them just for the sake of “doing Agile.” Instead, my approach is about being Agile—about applying the core principles to genuinely serve teams and organizations, not checking boxes in a rigid playbook. For me, Agile is a mindset.
Whenever I hear people say Agile is dead, they usually cite a few common reasons. They say the ceremonies are cumbersome, that retrospectives turn into blame sessions, or that estimating feels pointless. Others say Agile overpromises speed and constant delivery—that it’s all marketing spin. Some even see Agile as a cult with dogmatic rules and rituals that stray far from the spirit of its creators. And you know what? These experiences are all real, and they’re valid. But they aren’t Agile’s fault.
More often than not, these frustrations come from how Agile is introduced. It’s often by folks who took a three-day course, got certified, and suddenly became the “Agile expert” for their organization. They bring the best of intentions but lack experience with the nuances of Agile—and they try to force-fit what they’ve learned onto their teams. What you get is a one-size-fits-all application, which doesn’t work because Agile, at its heart, is contextual. It’s about adaptability.
When I say I’m being Agile, it starts with curiosity—by listening and learning. What is slowing the team down? What’s actually working? What does this organization value? How do power and influence flow within the team? Are people engaged or frustrated? Understanding these things takes time, but not much. It takes the willingness to ask the right questions and actually listen to the answers.
I’ll give you a real example from my own experience. I joined a company where teams in different departments were tasked with creating report packages that could eventually be productized. Instead, everyone was in reactive mode, spending most of their time just dealing with client complaints and customizing reports for specific requests. It was chaotic, and it was exhausting.
The key to turning this around wasn’t to slap on a framework like Scrum or Kanban and hope it stuck. I needed to address the root of the problem: the misalignment of roles and work. I reorganized the teams based on skills and capabilities—creating separate product and maintenance teams—but with the flexibility for people to move between them as product priorities evolved and their skills and interests changed. Having a dedicated maintenance team provided structure and consistency for client support while letting team members move between product and maintenance allowed for cross-training and growth.
To support all this, I introduced two-week development cycles. These allowed stakeholders to provide input more regularly, leading to better requirements and prioritization. This rhythm also helped everyone on the team anticipate where they were needed and when. In Agile terms, I formed Scrum teams for product development and a Kanban team for ongoing client support. But the real magic wasn’t in those labels—it was in listening to the pain points, recognizing individual strengths, and creating adaptive, iterative processes that allowed the team to keep growing.
That’s what I mean by being Agile. It’s not about the ceremonies or rituals. Those are just tools, and you use them when they make sense. Agile is about sensing and responding—to your team, to your clients, and to your product—and doing it in a way that empowers people rather than binds them to a rigid rulebook.
A lot of organizations think they need Agile, so they hire a consultant or bring in a SAFe practitioner, hoping for a one-size-fits-all transformation that will solve their problems. But Agile isn’t a miracle cure. You can’t “install” Agile like it’s a piece of software and expect it to work. And when those unrealistic expectations aren’t met—when the promised efficiency and continuous improvement fall short—people conclude that Agile has failed, or worse, that Agile itself is dead.
In reality, Agile is very much alive, though it might not always be called Agile. More and more, I see the deeper principles being embraced: iterative and adaptive workflows, self-organizing teams, safe-to-fail experiments, and stakeholder inclusivity. These concepts aren’t unique to Agile, but they embody what Agile is all about—adapting quickly, empowering people to make decisions, and finding better ways to work together. Agile, at its core, is about recognizing that complexity is everywhere and no one person has all the answers. It’s about creating space for teams to grow, experiment, fail safely, and improve—not just getting things done, but getting better at getting things done.
So, is Agile dead? Not by a long shot. Maybe the label has run its course, but Agile’s essence—that commitment to people, learning, and adaptability—is thriving, even if it wears a different name.
At Transformetic, we specialize in this kind of transformation—helping teams and organizations not just do Agile but be Agile. By applying human-centered, adaptive practices, we help build environments where people and processes can thrive. If your organization is ready to bring true agility to your teams, we’d love to help.
Leave a Reply