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.

Kanban versus Scrum – Detailed Comparison

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

Item	Scrum	Kanban
Primary Deliverables	Integrated Solutions	Completed Individual Work Items
Nature of the Work To Be Done	The work may have a high level of uncertainty and require considerable interaction with the customer to resolve the uncertainty as the project is in progress	The individual work items may be relatively well-defined and may not require much interaction with the customer to clarify requirements
Planning	Multi-level Planning Sprint-level Release-level Project-level	No Significant Planning Required
Roles	Scrum Master Product Owner Team	No Defined Roles
Time-boxing	Time-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
Workflow	Push-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

Kanban versus Scrum – 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.

Related Articles

Check out the following related articles on “Choosing the Right Project Methodology”:

• What Is the Truth About Agile versus Waterfall?
• Kanban versus Scrum – Which Agile Approach Do You Prefer?
• What Is Scrum and What Is Agile?
• What Are the Advantages and Disadvantages of Agile and Scrum?
• How Do You Choose Between Agile and Waterfall?
• What Is the Waterfall Model? How Is It Used?
• What is the Real Essence of Agile? What Are the Real Advantages?
• Modifying and Extending Agile and Scrum

Additional Resources

Resources for Agile Project Management Online Training.