Why Agile Isn't Working for Your Team: Six Signs of Agile Theater

Six patterns that look like agile delivery and produce none of it, with the first fix for each.

You were told to be agile without being told how. Here's how to tell practice from performance — and what each pattern costs.

A few years ago I sat through a retrospective that produced eleven sticky notes, three "action items," and no change of any kind. I know it produced no change because I checked the previous two retros. Same notes, slightly reworded. Same action items, still unowned. The team wasn't failing at retrospectives. The team had correctly figured out that retrospectives, as run in that organization, didn't matter, and had quietly stopped investing in them.

That's not an agile problem. That's agile theater, and it's a different thing entirely.

If your standups feel like status recitals, your sprints feel like two-week waterfalls, and your velocity chart gets more attention than your customers do, this article is for you. Not to tell you agile is dead. It isn't. Industry surveys keep landing on the same split: adoption is essentially finished — the 2024 State of Agile report put agile use at 71% of organizations — while doing it well is another story entirely. Claiming agile and practicing it are different things. Adoption is finished. Execution isn't.

The gap between those two is where theater lives. Here are the six patterns I see most often, what each one actually costs, and the first move that starts fixing it.

First, a working definition

Agile theater is performing the practices of agile without the problems those practices were invented to solve.

Every ritual in every framework exists because of a specific delivery problem. Standups exist because plans desynchronize daily. Retros exist because process problems compound silently. Backlogs exist because priority decisions get avoided. When the ritual continues but nobody in the room could name the problem it solves, the ritual has become costume.

That gives you a test you can run on anything your team does. I call it the function test: if you can't name the problem a practice solves for your team, this quarter, the practice is theater. Keep that test in mind. Each pattern below is a different way of failing it.

1. Ceremony theater

What it looks like: every meeting on the Scrum Guide schedule happens, on time, every sprint. Attendance is good. Outcomes are absent. The standup is fifteen minutes of people reporting to a manager. The review is a screen-share nobody interrupts. The retro produces sticky notes that evaporate.

What it costs: take a seven-person team and add up the ceremony hours across a sprint. It's usually somewhere between a full day and two full days of combined capacity. Theater means you're paying that price and receiving none of the goods: no resynchronized plan, no early feedback, no process improvement. It's the most expensive way possible to look organized.

The first fix: don't cancel the meetings. Run the function test on each one, out loud, with the team. "What decision or correction came out of this in the last month?" If the honest answer is nothing, change the format before you change the schedule. A standup that only surfaces blockers takes four minutes. A retro that tracks whether last retro's action actually happened builds accountability into the loop. Format follows function, and the function has to be named first.

2. Hybrid denial

What it looks like: the team runs sprints. The organization runs annual budgets, fixed-price contracts, and stage-gate approvals. Everyone pretends the second list doesn't exist. Sprint planning happens inside a delivery date that was signed before the team ever saw the work.

What it costs: this one costs trust. The team learns that "the backlog is flexible" is a polite fiction, because the end date isn't. Stakeholders learn that "agile" apparently means the team won't commit to anything. Both sides conclude the other is doing it wrong. Neither is. The seam between iterative delivery and fixed governance was simply never designed, so it fails in the open, repeatedly.

The first fix: name the hybrid. Say the quiet part in a planning session: "We iterate inside fixed constraints. Here's what's actually flexible — scope and sequence — and here's what isn't — the date and the budget envelope." Most teams I've worked with feel relief, not defeat, when someone finally says this. Hybrid isn't agile failure. Pretending you're not hybrid is.

3. The proxy product owner

What it looks like: the person prioritizing the backlog can't actually make product decisions. Real priority calls happen somewhere upstream, arrive as edicts, and reorder everything mid-sprint. The "product owner" relays, apologizes, and gets ground down between the team and the actual decision-makers.

What it costs: every priority conversation now takes two hops instead of one, and the answers arrive too late to plan against. The team stops trusting the backlog order because they've watched it get overturned too many times. Prioritization, which is the single highest-leverage activity in delivery, becomes decorative.

The first fix: stop trying to fix the role and start fixing the decision path. Map where priority decisions actually get made, then shorten the path: get the real decision-maker into one planning-adjacent conversation per cycle, even fifteen minutes. One direct conversation per sprint beats five relayed ones. If you're a BA reading this, you're often the best-placed person in the building to broker exactly that conversation.

4. Velocity as a performance review

What it looks like: someone outside the team starts watching the velocity number. Then comparing it across teams. Then asking why it dipped. The team, being rational, responds the only way a measured system can: the points inflate. Same work, bigger numbers, chart goes up, everyone's happy, nothing is true anymore.

What it costs: you lose the only honest forecasting signal you had. Velocity was designed as an internal calibration tool, a way for a team to sanity-check its own planning. The moment it becomes a scoreboard, it stops measuring throughput and starts measuring fear. And once your historical data is inflated, your forecasts are fiction, which means your date conversations with stakeholders are fiction too.

The first fix: take velocity out of every report that leaves the team. Report progress against outcomes instead: what shipped, what it did, what's next. If leadership pushes back, offer them the trade in plain terms — "you can have a number that goes up, or a forecast you can trust, but not both from the same metric."

5. The never-ending transformation

What it looks like: the agile transformation started years ago and never finished. There's still a transformation office, still coaches, still a maturity model with your team somewhere on level two of five. The transformation has outlived several of the executives who sponsored it.

What it costs: permanent transformation means permanent provisionality. Teams defer fixing their own process because "the new operating model" is always six months away. Worse, it teaches everyone that agile is something done to teams rather than by them, which kills exactly the local ownership the whole idea depends on.

The first fix: declare bankruptcy on waiting. Whatever the transformation timeline says, your team can apply the function test to its own practices this month, keep what earns its cost, and adapt what doesn't. You don't need the operating model to land before your retro produces a change. Improvement that waits for permission isn't agile by anyone's definition, including the sixty-eight words of the original manifesto.

6. The governance mismatch

What it looks like: the team is iterative, but everything above it speaks waterfall. Steering committees want milestone Gantt views. Status templates ask for percent-complete. The PM spends hours each month translating sprint reality into artifacts designed for a delivery model the team doesn't use, and the translation satisfies nobody.

What it costs: hours, obviously. But the deeper cost is credibility drift. When the governance layer keeps receiving reports that don't quite map to what it asked for, it concludes the team is evasive. When the team keeps producing artifacts that misrepresent how it works, it concludes governance is clueless. Both conclusions harden. Escalations get slower right when they need to be fast.

The first fix: don't fight the template, translate deliberately. Pick the three questions every governance audience actually needs answered — are we on track, what needs attention, what decision do you owe us — and answer those honestly in whatever format the template demands. Milestone language and iterative delivery are compatible as long as the translation is done once, deliberately, instead of improvised monthly.

What these six have in common

Not one of these patterns is caused by the wrong framework. Switching from Scrum to Kanban, or from SAFe to nothing, fixes none of them. They're all failures of the same kind: practice detached from purpose, running on institutional momentum.

Which is oddly good news. It means the fix doesn't require a transformation, a reorg, or anyone's permission. It requires one team, one practice at a time, asking the function test question out loud and having the nerve to act on the answer.

Run the diagnostic this week

Here's the Monday version. Take your team's standing practices — standup, planning, review, retro, estimation, reporting — and score each one against three questions:

1. Can anyone name the problem this practice solves for us, this quarter?
2. Has it produced a visible decision, correction, or change in the last month?
3. Would anything break if we stopped for two weeks?

Anything that fails all three is theater. Don't kill it in the same meeting; that's how you end up with a different kind of theater. Pick the single worst offender and rebuild it around its function. Then the next one. Most teams find that two focused cycles of this recover more capacity than any tooling change they made all year.

This article originally appeared in Analyst's Corner on Medium — read the original there, or follow new pieces on Substack.