Scrum Sucks

Original Article ↗ Hacker News Discussion ↗

Scrum and capital-A “Agile” are widely criticized here as bloated, ritualized frameworks that generate excessive meetings, cargo-cult metrics, and distorted incentives while doing little to improve actual software delivery. Many engineers report that Scrum works poorly for reactive or ops work, large organizations, and multi-team environments, and argue that problems blamed on “bad implementation” are in fact structural. Alternatives like Kanban, lightweight incremental planning, strong retrospectives, and team-defined processes are seen as more effective when paired with competent leadership, genuine trust, and a focus on outcomes rather than process theater.

Scrum in theory vs. reality

  • Many commenters distinguish between “textbook” Scrum and what companies actually do.
  • Common view: the framework is lightweight on paper but gets turned into a rigid, top‑down bureaucracy with certifications, jargon, and tools (especially JIRA, SAFe).
  • Some argue this inversion violates the Agile Manifesto’s “individuals and interactions over processes and tools.”

Meeting overload and productivity loss

  • Repeated reports of engineers having only 3–4 hours/day (or less) for real work due to ceremonies and status meetings.
  • Sprints, standups, grooming, PI planning, and “everyone” meetings often stack, especially when people are on multiple teams.
  • Attempts to cap meeting time can just move the same discussions into “ghost” meetings or chat.

Story points, estimation, and velocity

  • Intense frustration with story points: inflation, politicization, and conflation with time despite the “points ≠ time” mantra.
  • Teams often pad estimates or game burndown charts to look good, distorting planning.
  • Some see value in points for intra‑team planning; others advocate #noestimates or simple task counts/t‑shirt sizes.

Where Scrum works vs. fails

  • Works better for: small, focused product teams, consultancies selling sprints, or junior‑heavy teams needing structure.
  • Often fails for: Ops/DevOps, reactive/on‑call work, infrastructure, support, hardware, and large organizations with constant priority churn.
  • Sprints become de facto deadlines and encourage splitting atomic work into artificial tickets and half‑finished features behind flags.

Alternatives and adaptations

  • Many prefer Kanban for operations and ongoing product work: continuous flow, WIP limits, fewer ceremonies.
  • Others mention XP, ad‑hoc incremental development, or 37signals’ Shape Up as closer to Agile’s spirit.
  • Several teams effectively use a hybrid: minimal planning, short increments, few meetings, continuous delivery.

Culture, management, and retrospectives

  • Strong theme: bad culture and weak leadership will make any methodology painful; Scrum just makes dysfunction visible.
  • Critiques of “cargo cult agile” and inexperienced managers weaponizing process/metrics while avoiding real responsibility.
  • Retrospectives are seen by some as Scrum’s most valuable practice; where teams can honestly change the process, Scrum tends to work better.