Agile Theater: When You Change Words, Not Power

Agile failure is almost never a Scrum problem

I’ll say it plainly: most companies that fail at agile didn’t fail because their teams couldn’t run a stand-up. They fail because the people at the top never actually wanted to give anything up.

In my career, I’ve watched more agile transformations die from this than from any skills gap. The team knew the ceremonies cold. They could recite the difference between a story point and an ideal day. They had a board, a backlog, a velocity chart. And none of it mattered, because every real decision still had to climb the same ladder it always did, and the budget was carved in stone twelve months in advance.

That’s the part nobody wants to name. Agile isn’t a methodology you install. It’s a redistribution of decision-making power toward the people doing the work. If that redistribution doesn’t happen, everything else is cosplay.

Agile theater: the costume without the body

You know the setup when you see it. The vocabulary is perfect. There are Product Owners and Scrum Masters and tribes and squads. Sprints have cute names. Somebody bought the sticky notes.

Underneath, nothing moved.

1. Decisions still flow up. A team can plan all it wants, but the call on what actually ships gets made three floors above them, by someone who wasn’t in the room.
2. Money is frozen a year ahead. You committed to a fixed scope in a fixed budget cycle, then asked the team to “inspect and adapt.” Adapt to what? The contract was signed in Q4.
3. The roles exist, the authority doesn’t. Your Product Owner can’t say no to a stakeholder. Your team can’t change direction without a steering committee. They have the title and none of the keys.

This is agile on the surface and waterfall underneath. You changed the words, not the power. And people feel it immediately. They’re not stupid. They see that the meeting changed but the decision didn’t, and they quietly route around the whole thing the way they route around any process that wastes their time.

The test that tells you the truth

Forget the maturity assessments. Here’s the one question that exposes whether an organization is actually agile or just dressed up for the part.

A team comes to you and says: “We’ve been building this feature for six weeks. We’ve learned it doesn’t solve the problem we thought. We’re stopping.”

What happens next?

If you celebrate them, you’re agile. They just saved you months of waste, and they did it by being honest about a sunk cost most people would have buried under three more sprints to save face.

If you punish them, if there’s a hunt for who to blame, if the next planning session comes with tighter oversight, then you’ve built a machine that produces theater. Because you just taught every team in the building that learning is dangerous. They’ll keep shipping things they know are useless, on schedule, with a smile, because being right on a doomed plan is safer than being honest.

Agile without the right to be wrong is a lie. You can’t ask people to experiment and then treat every failed experiment as a personal failing. Pick one.

Cargo cult: importing the ritual, skipping the culture

There’s a special kind of failure I see all the time. A leadership team reads about how some admired company works. The famous “Spotify model.” Some scaling framework with a big diagram. And they decide: we’ll do that.

So they copy the structure. Squads, chapters, guilds, the whole vocabulary. And it does nothing, because those practices didn’t create that company’s culture. The culture created the practices. The structure was the residue of how those people already trusted each other and made decisions. You’re importing the residue and wondering why there’s no chemistry.

This is cargo cult thinking. Build the runway, light the fires, and wait for the planes to land, because that’s what you saw the successful ones do. The plane isn’t coming. You copied the ritual and skipped the thing that made the ritual work.

”We’ll be agile by Q3” is already the confession

My favorite tell. A leader announces the agile transformation as a project with a deadline. We’ll be agile by the third quarter. There’s a Gantt chart for it.

Stop and look at what just happened. You’re applying command-and-control logic, fixed dates, top-down mandate, a plan to be executed, to a thing whose entire point is the opposite. You’re trying to command your way into autonomy. You’re scheduling trust like it’s a software upgrade.

It doesn’t work that way, and the fact that you tried tells me you don’t understand what you bought.

Trust doesn’t get declared in a kickoff. Nobody walks out of an all-hands suddenly empowered because a slide said so. Trust gets built one concession at a time. You give a team a little real control over something that matters. Then you watch. And the ceiling doesn’t fall in. So you give them a little more. That’s the whole mechanism. It’s slow, it’s uncomfortable, and there’s no shortcut where you keep all the control and somehow get all the speed.

You can’t have the benefits without paying the price

Here’s what management actually wants. They want the speed of agile. They want the adaptability, the fast feedback, the ability to turn on a dime when the market shifts. Who wouldn’t.

What they don’t want is the price tag, which is letting go. Letting a team decide how to build. Letting them stop something that isn’t working. Letting money move when the learning says it should. Letting people be wrong on the way to being right.

The speed and the adaptability are not free features you bolt onto your existing org chart. They are what happens when decisions get made close to the work by people who have the context and the authority. Take away the authority and you’ve taken away the thing that makes it fast. You’re left with all the meetings and none of the payoff.

You can’t have one without the other. That’s not a process problem you can train your way out of. It’s a choice about power, and most organizations make it without ever admitting they made it.

What to actually do

If you’re leading one of these, here’s where it lands.

Give your teams a crystal-clear objective. Tell them the constraints out loud, the ones that are real: quality bar, budget, what has to stay visible, who they need to collaborate with across the org. Then get out of the way on the how. Hold them accountable for the result, not for following the dance steps.

And the first time a team tells you the thing they built doesn’t work and they’re killing it, watch your own reaction. That reaction is your transformation. Everything else is sticky notes.