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:
|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|
||No Significant Planning Required|
|Roles||No Defined Roles|
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||Continuous Flow Model (Pull Model)|
Work is started as soon as capacity is available to work on it
|Level of Integration|
|Process Definition and 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.
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.
You can find related articles on the topic of “Choosing the Right Approach” here:
You will find much more detail on this in my Online Agile Project Management Training.