Tag Archives: Kanban

Kanban versus Scrum – Which Agile Approach Do You Prefer?

I recently saw an online question that asked the question “Which Agile approach do you prefer – Kanban or Scrum?”. I decided that it was worth a blog post because I’ve seen this question several times. There are a couple of things wrong with this question:

  • It implies that Kanban and Scrum are interchangeable and
  • That the choice of one or the other is only a matter of personal preference

I don’t believe that either of those is correct:

  • Kanban and Scrum serve very different purposes
  • The choice of which one you choose should depend on what problem you’re trying to solve and objectively fitting the best approach to the nature of the problem. Personal preference or bias should not be a factor in that selection

How Are Kanban and Scrum Different?

Kanban and Scrum are very different kinds of processes and are intended for very different purposes.

Detailed Comparison

The table below shows a comparison of how Kanban and Scrum are different:

ItemScrumKanban
Primary DeliverablesIntegrated SolutionsCompleted Individual Work Items
Nature of the Work To Be DoneThe work may have a high level of uncertainty and require considerable interaction with the customer to resolve the uncertainty as the project is in progressThe individual work items may be relatively well-defined and may not require much interaction with the customer to clarify requirements
PlanningMulti-level Planning
  • Sprint-level
  • Release-level
  • Project-level
No Significant Planning Required
Roles
  • Scrum Master
  • Product Owner
  • Team
No Defined Roles
Time-boxingTime-boxed Sprints
Work is organized into fixed-length sprints
Each work item is handled individually – Kanban has no concept of grouping work items into a sprint
WorkflowPush-Pull Model
  • Work to be done is planned and prioritized to support a product road map (Push Model)
  • Within a sprint, work is started as soon as capacity is available to work on it (Pull Model)
Continuous Flow Model (Pull Model)

Work is started as soon as capacity is available to work on it
Meetings
  • Sprint Planning
  • Sprint Review
  • Sprint Retrospective
  • Daily Stand-ups
No Meetings
Level of Integration
  • Work can be organized into a hierarchical structure to facilitate integration
  • Sprints and releases can be defined to support Product Road Map deliverables
  • Work is organized as a single stream of work to be done with no hierarchy
  • Each item of work is treated independently and there is no mechanism for developing an integrated solution
Process Definition and Continuous Improvement
  • The process is intended to evolve as the project is in progress
  • Strong emphasis on continuous improvement with Sprint Retrospectives
  • The process may be well-defined and repetitive
  • No formal mechanism for continuous improvement

    General Comparison

    It should be apparent that Kanban is very streamlined and designed for efficiency but it is also very limited in what it is intended for:

    • Kanban has practically none of the overhead (planning, meetings, roles, etc.) of Scrum
    • However, it is intended for producing completed individual work items that do not require an overall integrated solution

    If you asked a developer which one they prefer, their choice might be obvious because developers like to write code without being burdened with too much overhead. However, that “overhead” is not unnecessary and can be essential in an environment where the goal is to produce a well-integrated solution that meets some overall business objective or solves a business problem.

    Overall Summary

    Kanban and Scrum are designed and optimized for very different purposes:

    • Kanban is designed for a continuous flow kind of process that may be somewhat repetitive. An example would be a customer service response queue or a queue of requests for business reports, The overall goal of a Kanban process is to produce as many completed individual work items as quickly and efficiently as possible
    • Scrum is intended for project work where there is an overall goal of producing some kind of integrated solution

    I’ve seen some people who want to abandon Scrum and move to Kanban because they don’t like some of the overhead that is built into Scrum; however, that “overhead” serves a purpose, provides value, and can be essential for projects that need to produce an integrated solution.

    Additional Resources

    This is only a very brief, high-level overview of differences between Kanban and Scrum. If you want to learn much more detailed information, check out my Online Agile Project Management Training Courses. The first course is free!