It's 9:47 AM. Your team is arguing whether a story is a 5 or an 8. Forty minutes in. Nothing has shipped.
This is Scrum theater—and most organizations are doing it.
The Pattern
Scrum theater is when ceremonies happen, artifacts get produced, roles exist, but continuous delivery of valuable software remains unachieved. Daily stand-ups become Jira recitals. Sprint planning produces estimates nobody believes. Burndown charts go sideways then magically complete on day 10.
Why It Happens
Scrum's design contains seeds of its own corruption:
- Time-boxing creates artificial pressure without delivery pressure
- Estimation rituals reward gaming over accuracy
- Velocity becomes Goodhart's Law in action
What Kanban Offers
Three things: visualization of work, WIP limits, and flow optimization. No ceremonies required. No roles prescribed.
WIP limits create the forcing function that makes flow problems painful and visible. When your "In Review" column hits its limit, code review becomes everyone's problem—immediately, not at sprint end.
The Predictability Question
Velocity is a terrible predictor—calculated from story points that are estimated, gamed, and inconsistent. Cycle time and throughput are measured from actual completions.
A mature Kanban team can say: "Based on our historical throughput, there's an 85% chance this feature set will be complete by March 15th." That's more honest than "we committed to it for Sprint 12."
Migration Path
- Make current state visible — Map actual workflow, visualize everything in progress, measure cycle time
- Introduce WIP limits — Start loose, tighten as flow improves
- Decouple from sprint boundaries — Replace commitments with queue replenishment
- Drop the theater — Eliminate ceremonies that don't serve delivery
The Real Question
It's not "Kanban vs Scrum?" It's: "What are we actually optimizing for?"
Most teams don't have a framework problem. They have a delivery problem their framework is obscuring.
Originally published at agilelie.com
Top comments (0)