Kanban vs. Scrum: What's the difference?

Original Article ↗ Hacker News Discussion ↗

Kanban and Scrum are contrasted as two agile approaches to organizing software work: Kanban as a lightweight, pull-based flow of prioritized tasks, and Scrum as a time‑boxed framework built around sprints, roles, and ceremonies. Many engineers favor Kanban for its simplicity, fewer meetings, and lack of story-point estimation, while Scrum is seen as useful for predictability, client management, and coordinating multiple stakeholders—but also prone to becoming micromanagement and ritual when misapplied. Several voices argue that outcomes depend less on the framework and more on company culture, management incentives, and how much process is allowed to overshadow actual problem‑solving.

Core Conceptual Differences

  • Many posts frame Kanban as:
    • A pull-based, continuous-flow method focused on visualizing work, limiting WIP, and improving flow.
    • Flexible, minimally prescriptive, more of a production/lean “philosophy” than a strict process.
  • Scrum is described as:
    • Push-based, time-boxed (sprints), with defined roles and ceremonies.
    • A prescriptive framework for iterative delivery and frequent inspection/adaptation.
  • Several note Kanban predates Scrum (originating in manufacturing), with Scrum seen as an IT adaptation.

Perceived Pros of Kanban

  • Simple shared board that everyone can see and reason about.
  • Fewer or no mandated rituals; lightweight coordination.
  • Fits “just give me a prioritized list and let me work” mentality.
  • Works well for operations, support, and reactive work where priorities shift rapidly.
  • Encourages focus on current top priority and WIP limits; some say it doubles/triples delivery compared to their prior Scrum experience.

Perceived Pros of Scrum

  • Helpful when there are multiple stakeholders, low trust, or external clients needing structure and a paper trail.
  • Time-boxing and velocity can reveal schedule risk earlier and help manage scope.
  • Some report that, used lightly and correctly, it improves team communication and social interaction.
  • Can shield teams from constant scope thrash by deferring new ideas to the next sprint.

Critiques of Scrum

  • Widely described as meeting-heavy, ritualistic, and prone to micromanagement.
  • Story points and velocity often seen as useless or gamed metrics that displace focus from value to “points completed.”
  • Forcing work into sprints can distort natural task boundaries and discourage deeper design or larger initiatives.
  • Many say real-world “Scrum” becomes cargo-cult agile: lots of ceremonies, little empowerment, and constant blame on “not doing Scrum right.”

Critiques of Kanban

  • Can also be misused: excessive meetings, broken WIP limits, or added pseudo-sprints via tools.
  • Without good policies and discipline, predictability and flow can degrade.

Broader Themes

  • Strong skepticism toward “agile theater” and management fads.
  • Repeated claims that culture, trust, and competent leadership matter more than any specific framework.
  • Some advocate hybrids (Scrumban), XP, or more traditional upfront design/waterfall for large, well-defined projects.