Agile theater: stand-ups, post-its, and zero decisions

Posted on August 12, 2026  •  12 minutes  • 2482 words

There’s a very specific moment in every dev’s life when you realize your company isn’t doing Agile — it’s doing theater.

It happened to me the day I walked into a meeting room, saw a wall covered in colored post-its, four columns with English names, and a giant poster that said “We are an agile organization” — and an hour later realized not a single important decision had been made in that room.

Everything was going to get “run up the chain.”

That’s when it clicks: you’re not on an Agile team, you’re in some kind of corporate escape room with a shiny Scrum aesthetic slapped on top.

The daily liturgy: 15 minutes standing up to prove you’re still alive

To me, Scrum is a religion, though I owe you that breakdown for another day. For now, we have to suffer through the ritual, because companies need the Agile sticker to sell.

The daily ritual is almost always the same. It’s 9:15, the “time for the daily” alarm goes off, you get up or log into Teams, and make the pilgrimage to the sacred ground of the whiteboard or the shared screen with the board.

The Scrum Master (or sometimes the Product Owner, or the Project Manager, or even the “Project Owner,” because not even religions get any respect anymore) throws out the line: “Alright, guys, 15 minutes, yeah?”

(I hate that “guys” thing — reminds me way too much of my time in Catholic school…)

And so the party begins:

• “Yesterday I was on ticket 3245, today I’m still on ticket 3245, no blockers.”
• “Yesterday PR review, today more PR review, all good.”
• “Yesterday I was in meetings, today too, I’ll fill you in later.”

You watch everyone recite their part like it’s the Lord’s Prayer, and you think that if someone ever said “I did nothing because I have no idea what we’re actually doing,” the silence would be so awkward it would tear open a black hole in the middle of the open-plan office.

What’s telling is what doesn’t happen in that daily. Nobody argues about priorities. Nobody dares to say “what we’re doing makes no sense.” Nobody says “this ticket is framed wrong, the real problem is something else.”

The daily isn’t for that. It’s so the people upstairs can see that “things are moving.”

Atlassian, in a recent article on Agile theater , put it pretty precisely: many organizations turn Agile ceremonies into a show meant to reassure management, not a mechanism for making better decisions. And it shows.

We changed the names, not the habits

Another day, someone sends an email announcing the company “has adopted Agile.”

You notice because, all of a sudden, people start changing their email signatures. The project manager, who’s spent twenty years running waterfall projects, is now the Product Owner. The team lead now signs off as Scrum Master. The Gantt chart becomes a roadmap. And the status meetings get renamed sprint planning, review, retrospective.

Everything new. Everything the same.

In theory, the Product Owner represents the business, prioritizes by value, talks to users, decides what’s in and what’s out. In practice, they still get handed the list of “stuff that needs to go in” from leadership — except now they turn it into Jira tickets, all filed under “priority: high.”

Saying no isn’t even on the table. And validating with real users? Yeah, right.

People with a lot of experience have gotten so fed up with this that they’ve coined some very descriptive terms: Cargo Cult Agile , for the ones who copy the events, artifacts, and names but change nothing underneath.

And you can see it coming a mile away: if all you’ve done is rename the org chart and stick up some post-its, what you have isn’t agility — it’s cosplay.

Sprints that are just waterfall with an Instagram filter

Then comes sprint planning. That’s where the theater really hits its stride.

A two-hour planning session gets booked, the backlog opens up, the Product Owner starts reading user stories like they’re reading straight out of the Federal Register, and the devs try to figure out what the hell a line like “as a user, I want to feel more cared for” is supposed to mean once it’s a backend ticket.

The sprint fills up with stuff. “Stuff,” not problems to solve. Because almost nobody ever asks “what do we want to learn this sprint” or “what hypothesis are we testing.” What gets proposed is a list of features that were already decided: this one, this one, and this one, because “they’re on the quarterly roadmap.”

More than one article on “Agile gone wrong” spells it out plainly: a lot of teams don’t iterate on problems, they iterate on inherited lists. Their sprints are just chunks of a plan that got locked down months ago, with no real room to course-correct.

That’s not Agile, that’s waterfall sliced up salami-style. Waterscrum, some people call it.

The funny part is that while everyone’s busy chopping features into tickets and slapping story points on them, nobody asks the important — uncomfortable — question: where did this list even come from? What evidence do we have that any of this matters?

The answer’s usually some mix of “the business asked for it” and “it was in the Q4 deck.” In other words: opinions with PowerPoint.

The art of pivoting without looking at a single data point

One of the most surreal moments in Agile theater is when the company discovers the word pivot. It’s a word that sounds great coming out of an executive’s mouth and gives off a real sense of smart, decisive movement.

“We’re agile, we pivot when the market changes.”

In theory, pivoting means changing your hypothesis once reality proves you wrong. In practice, at a lot of companies it means “changing your mind every two weeks because someone important had a new idea.”

Picture it: you’re mid-task, second week of the sprint, making solid progress, and suddenly a message drops — “top priority, we need to refocus on channel X because business said so.”

The story repeats itself. The retro says this creates stress. It gets written on a post-it. Nothing happens.

There are entire articles dedicated to this “feature factory” phenomenon where the organization never stops to check whether anything it’s doing actually works. Features get pivoted, roadmaps get pivoted, but beliefs never do.

Nobody looks at a real metric, nobody revisits a hypothesis, nobody admits “this isn’t working.” The only thing that ever changes is the color of the post-its.

The retro: we vent so well, we change so little

If you want to measure how much theater a company runs, don’t look at the daily — look at the retrospective.

A real retro is uncomfortable: it surfaces questions of power, of priorities, of things that need to stop.

A theater retro is a therapy board where everyone complains politely and goes home with a clean conscience.

I’ve sat through retros where the same points came up every time: too many interruptions, shifting goals, unclear requirements, managers barging into the daily for status updates, zero time to pay down technical debt.

They’d go up in columns, get dot-voted, and turn into “improvement actions.”

Two weeks later: same list, different order. Some people have even named it Groundhog Day Agile — Groundhog Day, but with Miro or Confluence.

The European Committee on Nothing. People talk, it gets noted, it gets filed away. Nobody touches the incentives, nobody questions who decides what, nobody protects the team’s time. But hey, the retro template keeps looking more professional every time.

The user, that guy who only exists in PowerPoint

In almost all of this theater, there’s one main character missing: the user. I don’t mean the “user persona with the cutesy name” from the Figma file — I mean actual people.

Ask how many people have talked to a customer in the last two weeks, and the silence is the kind you’d expect at a wake.

It’s assumed the Product Owner knows what the user wants. The Product Owner, in turn, usually knows what the business wants. And the business usually knows what the executive committee wants.

The actual user is a distant echo.

That’s why articles with titles like “Break free from the feature factory” keep popping up, with designers and product folks explaining how they spent years shipping stuff without knowing whether it eased a real pain point or just filled gaps on a roadmap.

And that’s how you end up with products full of features nobody uses, proudly marked “Done” across three different sprints.

The personal version: when you realize you’re set-dressing a bad play

Bring it down to the personal level, and Agile theater smells like this: you show up on a Monday, open Jira, look at your ticket list. Half of them are things you know aren’t going to change anyone’s life. A couple you already know will make the product worse (“one more toggle in a menu that’s already terrifying”). But there they are, each with its little number, its description, and its “commitment” label.

“Hey, why don’t we put this effort into fixing that other thing that’s been causing problems for a while?” They give you the look that says “yeah, we’ll get to it someday, but right now this is what’s in the sprint.”

Whatever’s in the sprint takes on a kind of sacred aura. You don’t touch it. You don’t question it. Doesn’t matter what the technical judgment says.

You close out the sprint with every ticket in the Done column. Velocity gets updated. The chart goes up in the review. You hear lines like “we’re getting better” because the burndown line looks more and more like a perfect diagonal.

That night, if you carry your developer’s conscience to bed with you, you might have a little trouble sleeping.

You can feel that the code is getting more fragile, the system more tangled, that you’re moving a lot but getting nowhere. And yet the numbers say the opposite. That’s when you notice something doesn’t add up.

The root of the problem: Agile without giving up the remote control

Nearly every serious analysis of why Agile fails lands on an idea that doesn’t sit well with the people upstairs: Agile requires letting go of control. Giving teams real autonomy. Letting the people closest to the problem make decisions. Accepting that you can’t predict everything in an annual Excel sheet .

This becomes crystal clear the moment something real happens.

Picture the retro where everyone just agreed, applause and all, that “business doesn’t touch the sprint halfway through.”

Two days later, the same director who nodded along in the retro sends a dev a direct Slack message (skipping the Product Owner, skipping the board, skipping everything that got signed off on 48 hours earlier) saying “this is urgent, needed yesterday.” The dev looks at the message, looks at the sprint board, and understands in three seconds which one actually carries weight: what got said in the ceremony, or what the person who signs the paychecks wants.

What a lot of companies do is the opposite of loosening the reins: they bolt the ceremonies on top of the same old model.

Locked roadmaps, dates promised to clients, strategic decisions made by people who haven’t touched the code or talked to a user in years. Then they slap a layer of Scrum on top and expect miracles.

What they get is exactly what articles like Agile theater or Agile Gone Wrong describe: more meetings, more red tape, more frustration, and not a trace of the benefits they were promised .

Can it be fixed, or is all that’s left applauding from your seat?

The good part is that not everything’s lost.

I’ve seen places that started backward: not “let’s do Scrum,” but “let’s decide what we want to improve.”

I’ve seen teams, for example, where someone put their foot down and said: “These dailies are useless, let’s change them or cut them.” And they actually experimented. Less frequency. More focus on real problems. Only run it if there’s actually something to decide. Suddenly, people stopped showing up in zombie mode.

I’ve seen retros where an uncomfortable decision got made, like: “For the next two months, we’re protecting dev time, and business can’t change priorities mid-sprint without going through this room first.”

There was resistance. There were long faces. There were fewer flashy “pivots.” In exchange, the team actually got to finish things properly. And, surprise, the product metrics improved.

I’ve seen Product Owners who said no. No to features with no data behind them. No to impulsive requests. No to “while we’re at it.” The same ones who later got called out in committee meetings as “difficult” or “inflexible.” Funny thing — their products were the ones with happy users.

And I’ve also seen the opposite: places where none of this happens, the theater keeps running, the good people leave, and the company is left with the set decoration and a certification hanging on the wall.

If you’re on one of those teams with stand-ups, post-its, plannings, and retros, but the important decisions always get made somewhere outside that room, you’re not the weird one for sensing that something smells like cardboard scenery. You’re just in the middle of a stage production.

The good news is that once you see the curtain and the stage lights, you can’t unsee them.

From there you’ve got two options: try to change the play… or go find a theater where, at least, the script has some truth to it.

Sources and references

For those of you who made it this far without wandering off to another team’s daily, here are the sources behind every argument:

• Agile Theater - Atlassian Community. An article examining how organizations turn Agile ceremonies into a performance meant to reassure management.
• Cargo Cult Agile - dev.to. An essay on teams that adopt the form of Agile without understanding or changing anything underneath.
• Cargo Cult Agile - Skeptical Agile. A critical look at the cult of form without any change to the real decision-making processes.
• Agile Gone Wrong: Scrum and the endless meetings - Pasquale Pillitteri. Concrete examples of Scrum implementations that spiral into meeting overload.
• Agile implementation fails: common problems and solutions - The Cranky PM. An analysis of the most common failures in Agile implementations, including the Groundhog Day pattern.
• 6 Feature Factory Anti-Patterns - Shane Drumm. Patterns that turn a product team into a factory churning out features with no real value.
• Break free from the feature factory - UX Design / Uxdesign.cc. A design and product perspective on how to escape the cycle of features with no real impact.
• Organizational autonomy and agility - YouTube. A talk on the fundamentals of real agility and the need to let go of hierarchical control.