Digital Product Engineering8.4 Agile, Scrum & Kanban
VOL. VIII · CH. 8.4 · PROJECT MANAGEMENT

Agile, Scrum & Kanban

Three related but distinct terms that get used interchangeably far more often than they should.

DivisionProduct Management
DifficultyIntermediate
Prerequisites8.3
Related8.5
1 min read · 328 words

8.4.1Definition

Agile is a set of values and principles favoring iterative delivery, responsiveness to change, and continuous feedback over rigid upfront planning. Scrum is a specific, structured framework implementing agile values through fixed-length sprints (8.5), defined roles, and regular ceremonies. Kanban is a different implementation emphasizing continuous flow and visualized work-in-progress limits rather than fixed iterations.

8.4.2Why It Exists

Rigid, fully-planned-upfront project management (often called "waterfall") struggles badly when requirements change mid-project — which they reliably do. Agile approaches exist to make responding to that change a normal, expected part of the process rather than a disruptive exception, trading some upfront predictability for the ability to adapt as real understanding develops.

8.4.3Scrum vs. Kanban

ScrumKanban
StructureFixed-length sprints (8.5) with defined ceremoniesContinuous flow, no fixed iterations
RolesDefined (Scrum Master, Product Owner)No prescribed roles
Best fitTeams benefiting from regular planning/review cadenceTeams with highly variable, continuously-arriving work (support, ops)

8.4.4Common Mistakes

  • Adopting Scrum's ceremonies without its underlying values — running the meetings while still managing the team with rigid, waterfall-style upfront planning underneath.
  • Forcing Kanban-style continuous work into artificial sprint boundaries, or forcing Scrum's sprint cadence onto genuinely unpredictable, continuously-arriving work.
  • Treating "we do agile" as a label rather than an actual practice, with none of the iterative feedback and adaptation the term is meant to describe.

8.4.5Best Practices

  • Choose the framework that matches the actual shape of the work — Scrum for planned, sprint-sized feature work; Kanban for continuous, variable-arrival work.
  • Focus on the underlying agile values (feedback, adaptability) rather than treating ceremonies as the goal in themselves.
  • Adapt the chosen framework's specifics to the team's actual size and context rather than following a rigid textbook implementation.
Real-World ExampleSupport and operations teams commonly favor Kanban over Scrum precisely because incoming tickets don't arrive in tidy two-week batches — a continuous-flow board with WIP limits fits that unpredictable arrival pattern far better than fixed sprints would.