Kanban vs Scrum: Why Flow Beats Theater for Real Delivery
Source: Dev.to
Introduction
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.
Scrum theater
Scrum theater is when ceremonies happen, artifacts get produced, and 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 Scrum can become corrupted
- Time‑boxing creates artificial pressure without delivery pressure.
- Estimation rituals reward gaming over accuracy.
- Velocity becomes an example of Goodhart’s Law in action.
Kanban fundamentals
Three things are essential:
- Visualization of work
- WIP limits
- Flow optimization
No ceremonies are required. No roles are prescribed.
Work‑in‑Progress (WIP) limits
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.
Metrics
- Velocity is a terrible predictor—it’s 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 15 .”
That’s more honest than “we committed to it for Sprint 12.”
Transition steps
- Make the current state visible – Map the actual workflow, visualize everything in progress, and 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.
Conclusion
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.