Scrum is the Least Bad Framework

I’ve run teams on Scrum, Kanban, SAFe, custom hybrids, and pure chaos. My conclusion: Scrum is the least bad option for most software teams. Not because it’s elegant — it isn’t — but because its flaws are visible, its feedback loops are short, and its ceremonies create forcing functions that actually matter.

What Scrum Gets Right

Timeboxing forces decisions

The sprint is a deadline with teeth. It forces the team to answer the question “what’s actually done?” on a regular cadence. Without a timebox, work expands, definitions of done drift, and “almost done” persists indefinitely.

Sprints make incompleteness visible. That visibility is uncomfortable and that discomfort is the point.

The retrospective institutionalizes learning

Most teams don’t get better over time. They accumulate habits and workarounds and stop questioning them. The retrospective is a scheduled moment to ask “are we getting better?”

It rarely works perfectly — retros can become complaint sessions or rubber stamps. But the ritual matters. The fact that it exists creates permission to name problems. That’s rare.

Velocity is honest feedback

Velocity is a blunt instrument but it’s real. Teams can’t inflate it without eventually delivering something. It becomes a mirror — not a performance metric, but a calibration tool. After a few sprints, the team has a ground truth about their actual capacity that no amount of estimation optimism can override.

It distributes ownership

Daily standups, sprint reviews, backlog refinement — Scrum distributes context and decision-making across the team rather than centralizing it in one PM or tech lead. Done well, the whole team understands the “why” behind the work, not just their ticket.

What Scrum Gets Wrong

It mistakes ceremonies for outcomes

Scrum’s ceremonies are means, not ends. Too many teams treat the sprint planning meeting as the deliverable rather than the thinking it’s supposed to generate. The ceremony becomes ritual. The ritual becomes noise.

Story points invite gaming

Points are supposed to abstract away time. In practice, teams convert them back to hours within a few months. Velocity becomes a proxy for performance, which breaks it as a calibration tool. Management pressure to “increase velocity” is a sign that the abstraction has failed.

The sprint cadence doesn’t fit all work

Two-week sprints make sense for feature development. They make less sense for infrastructure work, research, or creative work with irregular payoffs. Scrum squeezes all work into the same container regardless of fit.

It’s easy to do Scrum badly

The framework is simple enough that teams can follow all the motions without getting any of the benefits. Stand-ups become status reports. Retrospectives become complaint logs. Sprint planning becomes a negotiation over scope rather than a thinking exercise. Bad Scrum is worse than no process because it creates the illusion of structure while providing none of the benefits.

Why It’s Still the Least Bad Option

The alternatives have worse failure modes:

• Kanban without discipline becomes a pile of WIP with no forcing function for delivery.
• SAFe imposes so much ceremony that teams spend more time coordinating than building.
• “No process” works for a team of two and collapses at five.
• Custom frameworks require a level of maturity and discipline most teams haven’t built yet.

Scrum’s ceremonies are annoying but they create real feedback loops. When you run it and something breaks — velocity drops, the review produces nothing, the retro has no actions — you can point at the specific ceremony that failed and fix it. That debuggability is valuable.

How I Use It

I use Scrum as a baseline and adapt it deliberately:

• Sprint length varies by team maturity and work type (2 weeks for most, 1 week for early-stage)
• I replace story points with rough t-shirt sizes (S/M/L) or skip estimation on small, similar work
• I protect the retrospective — it’s the first thing that gets cut and the most important thing to keep
• I treat velocity as a team-internal tool only, never reported upward

The goal isn’t Scrum compliance. It’s the feedback loops Scrum was designed to create: regular delivery, regular inspection, regular adaptation.

Any process that delivers working software every two weeks and asks “what did we learn?” is probably fine. Scrum is a reasonable way to get there.