tl;dr: (from Karl Scotland)
- Scrum focuses on being agile which may (and should) lead to improving.
- Kanban focuses on improving, which may lead to being agile.
Kanban and Scrum are two different flavors of Agile development workflow. This post covers similarities and differences between the two approaches as applied to software development projects – as opposed to “change management” – an important distinction. (Hopefully you don’t have to choose between Scrum and Kanban and instead can find application for both!)
- The word “Kanban” originated from Japanese and translates as sign board or signal card. Its usage as a system control methodology was developed by Taiichi Ohno at Toyota in the 1950’s
- Scrum, sometimes incorrectly appearing in all caps, is not an acronym. The origin is from the game of rugby where the scrum is an “ordered” formation of players, used to restart play, in which the forwards of a team form up with arms interlocked and heads down, and push forward against a similar group from the opposing side. The ball is thrown into the scrum and the players try to gain possession of it by kicking it backward toward their own side. This resembles the process where a cross functional development team works as a unit to reach a common goal. Just attend a planning session or two… you’ll see what I mean…
Scrum is a form of agile that optimizes the estimation and execution of work. Scrum teams work in fixed intervals, known as sprints, which means they iterate on the product frequently. This allows the team to get feedback about each release, and to ensure maximum value back to the customer in the next sprint.
Kanban is a flavor that emphasizes the flow and continuous delivery of work. Limiting the number of items in flight creates an elegant workflow that lets kanban teams manage quality closely and deliver work to the customer continuously. A pull model makes the flow of work visible across the team, and exposes bottlenecks so the team can address them quickly.
- Both Kanban and Scrum focus on ‘getting to done’ for tasks in progress, reducing context switching
- Both at their core are summarized by the premise: Stop Starting, Start Finishing.
- Both limit WIP.
- Both use visibility and transparency to drive continuous process improvement.
- Both focus on delivering value (releasable software) early and often to minimizing risk
- Both are based on self-organizing and highly-collaborative teams who make their own decisions, strive for predictability, and a sustainable pace of development
- Both require breaking the work into pieces.
- Both embrace change as an opportunity, not a hindrance
- Both continuously optimize the release plan based on empirical data (velocity / lead time).
Ilan Goldstein has a great image from his book Scrum Shortcuts without Cutting Corners that nicely describes the power of Agile when discipline is maintained and teammates work together as one. I feel it applies to both Kanban and Scrum.
For sponsors and the business, the interlocking shields provide:
- Risk mitigation
- Visibility, transparency
- Continuous organizational improvement
- The opportunity for change as the result of frequent feedback loops
- Faster and predictable delivery of value
For the agile team they provide:
- Reduced context switching
- A sustainable pace of development
- The ability to make their own commitments
- No more “just me”
- And no more “us and them”
The ancient Spartans would full understand the core values of this approach
Because the team focuses on only a few things at a time, they work well together and produce excellent work. They deliver valuable items sooner.
Because they work as a team, they feel supported and have more resources at their disposal. This gives them the courage to undertake greater challenges and overcome adversity.
Because the team has great control over their own destiny, they are more committed to success.
As they work together, sharing successes and failures, they come to respect each other and to help each other become worthy of respect.
Some Tools for the Journey
When you create an Agile board in JIRA (Agile > Manage Boards > Create Board), you get to choose between one of two type – Scrum or Kanban – depending on how we want to run the project.
What kind of board am I looking at?
If you have an existing JIRA Agile board (previously known way back as Greenhopper), you can tell by looking at the top right if you’ve got a Kanban or Scrum version.
Scrum boards will have the “backlog” button enabled:
Note: It is not possible to switch an existing JIRA agile board from one type to another. Fortunately it is easy to create a new agile board of either type and use an existing JIRA filter.
Which is “Better” – Scrum or Kanban?
Really? It depends…
- Scrum is generally used by development teams who follow a roadmap of planned features for upcoming versions of their product. It sets up a regular cadence.
- Kanban is often used by teams who deliver maintenance releases. Kanban is also well suited to WebOps, SysAdmin and IT Support teams where frequent reprioritization is need.
- Learn more about Kanban Methodology as change management