by Aki Namioka, Sr. Agile Consultant
When an organization is deciding how to manage the work of an Agile team, two common paradigms are often considered: Scrum and Kanban. This article will discuss each paradigm at a high level, cover the advantages of each, and explain why a team might select one or the other.
Introduction to Scrum
Scrum’s history comes from software development. It has been around, in some form or another, since 1986 and is the most common Agile paradigm in software development. The current definition of Scrum was presented in 1995 by Ken Schwaber and Jeff Sutherland. It is described as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal.”
At Scrum’s core is the idea of working in iterations or “Sprints”, where a cross-functional delivery team works together to meet a set of goals that are defined by a Product Owner, i.e. somebody who can represent the business interest. A Sprint is a time box, e.g. 2 weeks. At the end of each Sprint, the delivery team demonstrates incremental business value to the Product Owner.
Here are the main activities that drive a Scrum project:
- Sprint Planning – The Product Owner and delivery team decides what features or “user stories” will get done in the coming Sprint. The output of a planning session is called a Sprint plan or Sprint commitment.
- Daily Scrum (standups) –Team members give an update on their work, and raise issues that might be blocking their work.
- Sprint Review – The delivery team demonstrates their work to the Product Owner and Stakeholders at the end of a Sprint. The Product Owner and Stakeholders can provide feedback and/or “approve” the user stories.
- Sprint Retrospective – The delivery team gets together with their Scrum Master or another facilitator, and reflects on what went well, and what could improve in their next Sprint.
Other activities that the Scrum team should do:
- Release Planning – The Product Owner and delivery team will get together before Sprint 1, to discuss the release goals, the key business drivers of the release, and the features that will be in the release. A release is typically about 3-6 months of work.
- Backlog Grooming – The Product Owner and delivery team gets together on a regular basis to look at the backlog of work to adjust the priorities based on current business drivers, and to clarify the user story definitions and acceptance criteria. This will help the team work more efficiently during Sprint planning meetings, and gives the Product Owner the opportunity to adjust priorities for upcoming sprints.
Advantages of Scrum
Since Scrum is the predominant Agile paradigm, there are lots of tools, on-line resources, and training that discuss Scrum in detail.
The Scrum Alliance has an extensive program of Scrum related certification. This certification process helps to ensure that the quality and skills of Scrum practitioners are consistent. For example, a Certified Scrum Master (CSM) is able to demonstrate basic Scrum knowledge and should have the skills to be a Scrum Master.
Because Scrum is so popular, this is a good model to select for new Scrum teams. The amount of material and training that is available will help a new team come up to speed on the concepts of Agile and Scrum. It will expose the Scrum team to the benefits of Agile, such as responding quickly to changing business requirements, continuous quality improvement through retrospectives, and cross-functional teams working together to iteratively deliver business value.
Kanban (means sign or billboard in Japanese) comes from the Lean manufacturing industry, which was first developed in Japan in the 1940s. Ironically, both Scrum and Kanban have their roots in Japan.
Lean as a model for software development was first introduced by the Poppendiecks in 2003. The principles of Lean and the principles of Agile had several similarities and the Lean paradigm was quickly embraced by the Agile community.
Lean projects use a Kanban board to track the delivery team’s work. Two key elements of the Lean/Kanban style of working are (1) making the work visible, and (2) imposing a Work In Progress (WIP) limit. WIP limits are an important concept, and several examples from manufacturing illustrates the advantages of imposing a WIP. A hilarious video on what happens when there is insufficient WIP can be viewed here.
Unlike a Scrum team, a Kanban team doesn’t plan Sprints. Instead, they work from a continuously prioritized backlog. When the WIP falls below the limit, the next user story is pulled from the top of the backlog and the delivery team starts working on it.
Here are the main activities which drive a Kanban project:
- Planning/Backlog Grooming – The Product Owner and delivery team gets together on a regular basis (maybe once a week) to look at the backlog of work to adjust the priorities based on current business drivers, and to clarify the user story definitions and acceptance criteria. This will help ensure that the backlog always reflects the current business priorities.
- Daily Standups –Team members give an update on their work, and raise issues that might be blocking their work. They can also pull in a story from the top of the backlog when there is room in the WIP.
- Retrospective – The delivery team gets together on a regular basis with their Agile facilitator, and reflects on what is going well, and what could improve.
- Demo/Feature Review – The delivery team demonstrates their work to the Product Owner and Stakeholders. The Product Owner and Stakeholders can provide feedback and/or “approves” the user stories.
Other activities that a Kanban team should do:
- Release Planning – The Product Owner and delivery team will get together to discuss the release goals, the key business drivers of the release, and the features that will be in the release. A release is typically about 3-6 months of work.
To understand how long it takes to finish a user story, cycle time is often recorded for each story as it is completed. This is the number of days that a delivery team spends on a story, i.e. the number of days from when it is pulled onto the board from the backlog, to the day it is “DONE”.
Advantages of Kanban
Kanban has a simpler project structure. There are less meetings to attend, and the meetings are usually shorter, but perhaps more frequent. I call it just-in-time planning. Before I facilitated my first transition from Scrum to Kanban, I talked to a developer who had worked in both paradigms. She said she loved Kanban because the team just focused on the most important stories and got them done. She felt more productive in this model, and she said team morale was high because they didn’t have to worry about missing Sprint commitments.
A mature Agile team may find Kanban appealing as there is a reduction in overhead. A mature team is one that understands their domain and technology well enough that their cycle time is predictable. They also need to have the skills to work with the Product Owner in creating a body of user stories that are all about the same size. This will make their cycle time more predictable, and will give the Product Owner the information she/he needs to anticipate feature releases and manage the backlog.
Another advantage of Kanban is that it can be immediately responsive if business priorities are changing quickly. If the Product Owner feels restricted by the time limitations of a Sprint, then Kanban might be a good alternative as the delivery team can respond to changes in the backlog more quickly.
Some Scrum teams have implemented a Kanban-like board as a means of making the work more visible. However, they adhere to the basic Scrum structure, and deliver based on Scrum Commitments. This style of Scrum is called “Scrumban” , and is an easy way to reap some of the benefits of Kanban, without too much disruption to the team.