Religion asks you to believe in something bigger than yourself. The Agile methodology, on the other hand, isn’t a belief system or a prayer. It’s a methodology.
And processes within any methodology are meant to be continually inspected and adapted to keep delivering value.
But somewhere between the manifesto and the meeting room, a lot of organizations started treating Agile like a set of commandments. And when a methodology becomes doctrine, you don’t get agility. You get a new set of rules with branding. You get the same rigidity you were trying to escape, wearing different robes.
This isn’t just an Agile problem. It’s the pattern underneath every approach that promises to fix how organizations work.
the original problem.
Waterfall landed itself a soured reputation. Some of it wasn’t entirely warranted, while much of it was undeniable. Rigid phase gates. Extensive documentation before a single line of code gets written. Change requests that take longer to process than the change itself. Months of planning for a product the market no longer needs by launch day.
To be fair, Waterfall made sense for the work it was built around. Constructing a high-rise. Engineering a bridge. Projects measured in years or decades, where requirements were stable, phases were sequential by necessity, and the cost of changing course mid-stream was genuinely prohibitive. In those contexts, structure wasn’t bureaucracy. It was the point.
But technology doesn’t build on that timeline. Markets shift. User needs evolve. A product planned in January can be irrelevant by June. The organizations that recognized this first didn’t just need a faster process. They needed a fundamentally different way of thinking about how work gets done. That’s what Agile was built to answer.
Organizations that lived through painful Waterfall failures didn’t just want a new methodology. They wanted freedom. A way to build, learn, and adjust without getting buried in process.
Agile promised that. And for teams that understood what it actually was, it delivered.
But Agile was never meant to be the whole answer. It was meant to be a better option. There’s a difference. And that distinction gets lost the moment an organization stops treating it like a methodology for guidance and starts treating it like a faith for adherence.
what religious adoption actually looks like.
Here’s the pattern. A new approach arrives that solves real problems. Organizations adopt it wholesale. And somewhere in that adoption, the approach stops being a tool and starts being a doctrine.
In Agile shops, it looks like the Scrum Master who refuses to acknowledge work that can’t be story-pointed. The team that won’t speak to a stakeholder outside a defined ceremony. The sprint that ends with an incomplete deliverable because the timebox is sacred, even when finishing it would have taken two more hours.
In Waterfall environments, the framework becomes untouchable. Not because it’s serving the work, but because no one has stopped to ask if it still does.
And now, we’re seeing history repeat itself with the adoption of AI. The tool becomes the authority. Outputs get accepted without inspection. Decisions that require human judgment get handed to a system that has none. Organizations move fast, and that speed makes it harder to notice when they’re moving in the wrong direction.
These aren’t examples of progress. They’re examples of abdication. The methodology, the framework, the tool, all standing in for the thinking that should have happened first.
When following the approach becomes more important than understanding what the organization actually needs, nothing has changed. The wrapper is different. The dogma is the same.
three real examples.
WATERFALL
a 30-minute fix. a three-week wait.
In one engagement, a change request came in for an adjustment any senior team member could implement in half an hour. Both the work and the need were clear, and an agreed upon approach was established. But it still took three weeks to obtain the approval to implement. It went into the queue. Days passed. Then a week. Then two. By the time it cleared the approval chain, the context had shifted, the team had worked around it, and the original urgency was long gone. The framework didn’t protect the organization. It cost it. Three weeks of delay, accumulated friction, and a team that quietly learned not to raise small issues because small issues carry the same overhead as large ones. That’s not governance. That’s bureaucracy that forgot its own purpose.
AGILE
the update that wasn’t “a Scrum Master’s job.”
We watched this one play out in real time. After daily scrum, product needed visibility into a critical ticket. A straightforward note in the task management system. The Scrum Master refused. Not because it wasn’t useful. Not because the team disagreed. Because “that’s not a Scrum Master’s job.” What that Scrum Master missed was simple. The alternative was asking the development team to provide their updates verbally in standup and then repeat them digitally themselves. More time away from building, more cognitive overhead, less clarity for the stakeholders who needed it. Citing the playbook to avoid a two-minute task isn’t principle. It’s rigidity dressed up as process fidelity. And it’s exactly what happens when a methodology becomes a religion. The ceremony matters more than the people the ceremony is supposed to serve.
ARTIFICIAL INTELLIGENCE (AI)
scanning slack for sentiment to replace conversation.
A client came to us after rolling out an AI tool to scan internal Slack messages and surface insights about morale, engagement, and communication patterns. The goal was to understand team sentiment. A reasonable one. The output looked compelling. Dashboards. Trends. Flags for at-risk team members. And emojis that promised to make it more human-centric. What it never surfaced was whether people felt safe enough to say what they actually think. Passive data collection measures what people are willing to say in a given channel. It doesn’t measure whether the culture supports honest feedback. Those are two different things. The tool produced data. It didn’t produce understanding. And acting on that data without making that distinction doesn’t improve team health. It sidesteps the harder work of building an environment where people will tell you the truth directly. Human experience isn’t a gap that AI fills. It’s the thing AI can’t replace. All three situations share a root cause. When organizations adopt a methodology, a framework, or a tool without building a culture of critical thinking around it, compliance fills the gap that judgment should occupy. The approach becomes the authority. The work becomes secondary.
None of this means the answer is always “yes.” A Scrum Master who lets stakeholders bypass the team to assign work directly isn’t being flexible. They’re failing the team. And a Scrum Master who allows a team member to opt out of ceremonies because they don’t feel like they apply isn’t being adaptive. They’re losing the framework entirely, while their role is intended to hold that line from both directions. Protecting sprint integrity, shielding the team from unplanned work, holding the line on process when the process is working. All of that is exactly what the role is for. There are absolutely moments where the right answer is “no, and here’s why.”
But there’s a third response that requires the most skill. “Possibly. Let’s take a look together.” Not every challenge to the process is an attack on it. Sometimes a team member pushing back on a ceremony is surfacing something worth examining. Sometimes a stakeholder request that doesn’t fit the sprint is a signal that the backlog needs a conversation, not a hard stop. The practitioner who can tell the difference between a boundary worth holding and an assumption worth questioning is the one the team actually trusts.
The difference isn’t whether you say no. It’s whether the response, whatever it is, serves the team and the work, or just the framework. One is judgment. The other is compliance wearing judgment’s clothes.
the cost.
Doctrine doesn’t look like failure on a dashboard. It looks like a team that’s moving but not in the right direction. A product that meets every sprint goal and misses the business objective. AI-generated insights being acted on without anyone asking what question was actually being answered.
Organizations feel the friction before they can name it. People stop trusting the process. Teams start working around the ceremonies instead of through them. Leaders pull back on the initiative because they were promised adaptability and got a new set of rules to follow.
Nobody’s measuring outcomes. Adherence became the goal somewhere along the way. The work didn’t change that.
what the source material actually says.
We strongly encourage you to revisit the Agile Manifesto. Read it with fresh eyes. It values individuals and interactions over processes and tools. Responding to change over following a plan. It never asked you to abandon documentation, processes, or structure entirely. It asked you to recognize what matters most when the two are in conflict.
The principles are equally clear. Deliver working software frequently, welcome changing requirements, reflect regularly and adjust. The word “rigid” does not appear once.
Inspect and adapt isn’t just a Scrum principle. It’s the whole idea. Look at what the organization actually needs and build the approach around that. Not the other way around.
Most organizations that get this right run hybrid models because the work demands it. A regulated deliverable may need documentation. A fast-moving product team may need two-week cycles. Some problems genuinely benefit from AI. Others require a human conversation that no tool can replicate. None of those choices are a compromise. That’s the truest form of agility. Not the framework, but the judgment to know when and how to use it.
the bottom line.
Agile isn’t a religion. Neither is Waterfall. Neither is AI.
The goal was never to become an Agile shop, preserve a methodology, or roll out the newest tool. The goal was to build things that work, for people who need them, better than the alternative.
When the approach starts getting in the way of that, something needs to change. That might be a practitioner willing to question what they were certified in. It might be a leader willing to examine the governance structure they built. It might be a team willing to ask whether the tool they’re relying on is actually answering the right question.
Most of the time, it’s all three.
The work doesn’t care which role fixes it. It just needs someone to start.
