Agile as ritual: the gap between ceremony and actual agility

At my first startup in Bangalore, I was the person who bought the Agile textbook. I am not proud of this. I read it cover to cover, highlighted passages, and then introduced every ceremony I could find to a team of seven people who had been shipping perfectly well without any of them.

We had stand-ups. They lasted forty-five minutes. People leaned against walls, shifted their weight, checked their phones while someone explained a database migration in the kind of detail that belongs in a document, not a morning ritual. We had sprint planning. It took an entire afternoon. We had retrospectives every two weeks where we identified the same three problems (unclear requirements, too much scope, not enough testing) six sprints in a row. We wrote them on sticky notes, put them on a board, and then ignored them until the next retro, when we wrote the same problems on fresh sticky notes.

The process felt agile. The output was waterfall with post-it notes.

I thought we were doing it wrong. So I added more structure. More templates. More tracking. But nothing about how we actually built the product changed. We still waited for one person to approve every decision. We still committed to scopes that nobody believed in. We still treated the sprint as a container for work that had already been decided, not a framework for adapting to what we learned.

That was my first encounter with what I now call the ceremony trap.

The ceremony trap

The ceremony trap is not that teams do the wrong rituals. It is that the rituals become the product. You start measuring whether the stand-up happened, not whether the stand-up changed anything. You track sprint velocity, not whether the sprint delivered value. You run retrospectives on schedule, not because anyone expects the outcome to be different from last time.

And the trap is seductive because it feels responsible. You are doing the meetings. You have a board with columns and cards moving left to right. From the outside, it looks like a functioning Agile team. From the inside, everyone knows better. But nobody says so, because the ceremonies provide cover.

GitLab's DevSecOps survey found that 67% of teams admitted to sacrificing quality for speed. But I would frame that differently. They were not sacrificing quality for speed. They were sacrificing quality for the appearance of speed. The sprints created urgency. The ceremonies created the illusion of responsiveness. But the underlying decision-making structure, the hierarchy of who decides what gets built and when, had not changed at all.

This is what I call Agile theatre. The performance of agility without the substance of it.

The kitchen did not change

Imagine a restaurant that renovates the dining room. New furniture. New lighting. New plates, the kind with the wide rim and the small portion artfully placed in the centre. The menu has a new typeface.

But the kitchen is the same. The same chef, the same suppliers, the same recipes, the same workflow where everything bottlenecks through one person who insists on tasting every dish before it goes out. The plates look modern. The food has not changed.

That is what most Agile adoptions look like. The ceremonies are the dining room renovation. The org chart, the approval chains, the power dynamics, the way decisions actually get made: that is the kitchen. But most organisations renovated the dining room without touching the kitchen.

I saw a more sophisticated version of this at Freshworks. A product team running clean two-week sprints. Ceremonies on schedule. Velocity tracked. Burn-down charts on a screen in the team area. From the outside, textbook Agile.

But the PM pre-decided every item before sprint planning. The "planning" session was a presentation. The PM walked through what they had already committed to stakeholders, and the team listened, nodded, and assigned story points to work that had been scoped without their input. Sprint planning was not planning. It was an announcement wearing the costume of collaboration.

I asked in a retro once why nobody ever pushed back on scope during planning. The room went silent. Not the productive silence that follows a good question. The silence that means everyone knows the answer and nobody wants to say it.

The answer, which someone finally offered after I let the silence sit for an uncomfortable twenty seconds, was simple: pushing back did not change anything. The PM had already committed upward. The stakeholders had already been told. The scope was fixed before the ceremony began. The ceremony existed to make a top-down decision look like a team decision.

That team was agile in vocabulary. It was waterfall in every way that mattered.

Where agility actually lives

Agility lives in decisions, not ceremonies. A team is agile when it can change direction based on what it learns. When a sprint reveals that the initial assumption was wrong, an agile team adjusts scope for the next sprint. A ceremonially agile team keeps building what was originally planned because the PM already told the VP it would ship.

The real test is not whether you have stand-ups. It is what happens when someone says, mid-sprint, that the thing you are building is the wrong thing. In a genuinely agile team, that observation changes the plan. In an Agile theatre team, that observation gets noted, possibly acknowledged, and then shelved because the commitment has already been made.

But here is the uncomfortable part. Genuine agility requires something most organisations are not willing to give: distributed authority. If the team cannot make real decisions about scope, priority, and direction without escalating to someone outside the team, it does not matter how many ceremonies they run. The agility is cosmetic. The power structure is the process. Everything else is set dressing.

I have worked across nine different organisational contexts, from three-person startups to global enterprises. The pattern is consistent. The teams that were genuinely agile were not the ones with the best ceremony discipline. They were the ones where the team had real authority to change course. Not permission to suggest changes. Authority to make them.

That distinction sounds small. It is enormous.

The retro that never changes anything

The retrospective is the most revealing ceremony. It is where the gap between Agile theatre and genuine agility becomes impossible to hide. A retro is supposed to produce change. The entire point is that the next sprint is different from the last one.

But in most teams I have observed (and a few I have led, including that first startup), the retro produces a list. The list goes on a board. The board gets photographed. And the next sprint begins exactly as the previous one ended.

The retro becomes a confession ritual. You name the sins. You feel briefly lighter. Nothing changes. You come back in two weeks and confess the same sins again. It is performance without consequence.

The teams where retros actually work are the ones where someone in the room has the authority to act on what the retro reveals. Not escalate a suggestion. Change the practice. That week.

But most organisations treat the retro as feedback, not as a decision-making moment. And feedback without authority is just venting with structure.

The ceremony trap is comfortable. It provides the language of progress without the friction of actual change. It lets organisations tell themselves they are agile while preserving every hierarchy, every approval chain, every political dynamic that existed before anyone had heard the word sprint.

Agility was never a set of meetings. It was a willingness to be wrong in public and adjust in real time. Most organisations adopted the meetings. The willingness was never part of the package.