When Methodology Becomes Dogma: A cautionary tale of how the methodology meant to liberate teams can become their prison
The Agile Manifesto was revolutionary when it emerged in 2001. Its authors rebelled against rigid, documentation-heavy processes that stifled creativity and responsiveness. They championed “individuals and interactions over processes and tools” and “responding to change over following a plan.”
Yet twenty-three years later, we’ve witnessed something the manifesto’s creators likely never anticipated: agile itself becoming the rigid dogma it was meant to replace.
The Ceremony Trap
Walk into many organizations today, and you’ll find teams trapped in what I call the “ceremony trap.” They hold their daily standups religiously—even when half the team has nothing meaningful to share. Sprint planning sessions stretch for hours, dissecting user stories with the fervor of biblical scholars. Retrospectives follow the same tired format, week after week, generating action items that quietly die in the backlog.
These teams mistake activity for progress, ritual for results.
The telltale signs:
- Meetings are held because “that’s what agile teams do,” not because they add value
- Team members fear suggesting changes to established practices
- More time is spent discussing process than solving problems
- The word “ceremony” is used unironically
The Metrics Obsession
Nothing illustrates agile’s dogmatic turn quite like our obsession with metrics. Velocity becomes gospel. Story points are debated with religious intensity. Burndown charts are scrutinized like ancient prophecies.
But here’s the uncomfortable truth: these metrics were meant to be tools for teams to understand themselves better, not weapons for management to wield. When velocity becomes a target rather than a measure, teams game the system. When story points become currency, inflation is inevitable.
I’ve seen teams spend more time in story point poker sessions than actually building software. The tail is wagging the dog.
The Framework Wars
Perhaps nowhere is agile dogma more apparent than in the framework wars. SAFe evangelists battle Scrum purists. LeSS advocates clash with Spotify model enthusiasts. Each camp claims to have found the “true path” to agility.
But frameworks are just scaffolding. They’re meant to support the building, not become the building itself. When teams become more loyal to their chosen framework than to the principles of adaptability and collaboration, they’ve lost the plot.
The most agile teams I know? They cherry-pick practices from multiple frameworks, adapt them to their context, and aren’t afraid to abandon what isn’t working.
The Consultant Industrial Complex
The transformation of agile from philosophy to product has created a thriving industry of consultants, coaches, and certification bodies. While many provide genuine value, the commoditization of agile has also led to a “one-size-fits-all” mentality.
Cookie-cutter transformations ignore context. Certification programs create armies of practitioners who know the rules but not the reasoning. The result? Teams that can recite the Scrum Guide verbatim but struggle to adapt when their context changes.
The Irony of Inflexible Flexibility
The greatest irony of dogmatic agile is how it violates agile’s core principle: responding to change. When teams become slaves to their chosen methodology, they lose the very adaptability that agile was meant to foster.
I’ve watched teams stick rigidly to two-week sprints even when their work naturally fell into different rhythms. I’ve seen organizations mandate daily standups for teams that collaborated continuously throughout the day. The methodology became more important than the outcomes.
Finding the Way Back
So how do we rescue agile from itself? How do we return to the principles while avoiding the dogma?
Start with why, not how. Before implementing any practice, ask: “What problem are we trying to solve?” If you can’t articulate the purpose, you’re probably engaging in cargo cult agile.
Embrace empiricism over ideology. Try things. Measure results. Adapt accordingly. The scientific method works for software development too.
Remember the manifesto. Those four value statements aren’t suggestions—they’re priorities. When your process conflicts with these values, trust the values.
Question everything, especially success. Just because a practice works doesn’t mean it should be sacred. Context changes. Teams evolve. What worked yesterday might hinder tomorrow.
Focus on outcomes, not outputs. Are you delivering value to customers? Are team members engaged and productive? Are you responding effectively to change? These matter more than perfect adherence to any framework.
The True Spirit of Agile
Agile was never meant to be a destination—it was meant to be a journey. It’s not a set of practices to master but a mindset to embody. The moment we stop questioning, adapting, and evolving our approach is the moment we’ve betrayed agile’s fundamental spirit.
The far side of agile isn’t a place we visit—it’s a trap we fall into when we stop thinking and start following. The antidote isn’t abandoning agile principles but remembering why we embraced them in the first place: to build better software, create better teams, and respond more effectively to an ever-changing world.
In the end, the most agile thing you can do might be to question agile itself. After all, that’s exactly what the manifesto’s authors did twenty-three years ago.
What dogmatic practices has your team fallen into? How have you successfully challenged established agile orthodoxy? Share your experiences—the agile community grows stronger when we learn from both our successes and our sacred cows.
Agile Ways 