Scrum v. Kanban: Comparing and Contrasting These Agile Approaches

When talking about Agile processes and frameworks, there is often the discussion about Scrum versus Kanban. This conversation revolves around the purpose of each of these approaches and what might lead a team to adopt one or the other.

But there’s one big thing that is often ignored in these discussions: Scrum and Kanban are not alternatives to one another. 

Scrum as a Framework

To understand the differences between Scrum and Kanban, let’s first look at Scrum.

Scrum is a framework. This means that Scrum is a set of rules for a team to follow that creates boundaries around the way that they work. The boundaries exist to help the team detect things that are not working for them so they can make improvements. In doing this, one of Scrum’s main superpowers is making problems visible. Because Scrum makes the biggest impact on the team practicing it, the problems that are uncovered are most evident to the Scrum team and usually have to do with how the organization interacts with the Scrum team. As the problems become transparent to the team, organizational leaders find themselves with a Scrum Master who is asking them to make changes to the organization so that everyone is working in a more Lean and Agile way.

In this sense, Scrum often creates friction within organizations.

One way of dealing with this friction is for the organization to accept it and understand that the sparks flying between people are signals to make changes to the environment. These changes involve getting rid of hierarchical processes that get in the way of Scrum. The assumption here is that anything causing friction in the Scrum process is non-Agile in nature, and it needs to be removed. 

The other reaction to the friction caused by Scrum is to see it as an annoyance and start customizing Scrum so that the friction will stop. However, when the Scrum framework is customized, this signals that the organization isn’t willing or ready to solve the problems that Scrum has revealed. Instead, the problems are accepted either because the organization doesn’t believe they are problems, or because they are concerned about their ability to fix them. 

Kanban as a Visualization Tool

On the other hand, there is Kanban.

Kanban is not a framework and it doesn’t create boundaries for a team in the same way Scrum does. Kanban is a way of visualizing work using vertical columns to represent stages in the workflow and cards in the columns to represent the elements of the work. There are few rules in Kanban, and a team or an individual can adopt Kanban without anyone becoming aware they have done so.

Because of Kanban’s flexibility, it allows for adoption from the most basic implementation, all the way to a fully rigorous implementation. Any team in any environment anywhere can use it to manage their flow of work, keeping it isolated to the work they have complete control over. This makes Kanban a great strategy for a team to adopt when they are working in an environment where Scrum’s friction will not be tolerated.

What Kanban Shows You

At its most basic function, Kanban visualizes what is happening within the workflow. By looking at the Kanban board, every work item of value can be seen whether it’s waiting to be selected for work, traversing the process, or sitting in a completed state. (From there, the team’s level of psychological safety and transparency will determine how accurate that visualization is.)

Once you can see what is happening, you can start to draw conclusions about why it is happening. A CEO viewing a Kanban board of all the projects in their company for the first time is often shocked by what’s presented and ask, “Are we really doing all of that? Do we really need to be doing all of that?”

This is typically the first realization that Kanban brings: We have problems we cannot see. Visualization of work helps to cure organizational blindness and bring awareness to the fact that there are issues no one was even aware of. The CEO above may respond to this new information provided by Kanban and start vetoing work that is too costly or is lower priority than other work items.  

Kanban’s Measures

Now that the visualization is available, the next step is to start measuring what is happening throughout the workflow.

• Counting how many items are completed per day, week, or month as appropriate gives us a result called throughput.
• Counting the number of days from the time a work item is pulled from the queue for work until it is fully complete gives us its cycle time.
• Counting how long one item takes to cycle through the system while it’s in progress is called item aging.

These numbers provide valuable insights into how work is getting done. Just a few insights include:

• If we know that one type of work takes an average of 30 days to complete, then we now have an idea forming about how long it will take in the future rather than relying on assumptions. With data to rely on, we have achieved a basic form of predictability.
• Worry may creep in about how long it takes for items to traverse the process, and we may wonder if having too many items in progress at once could be slowing the whole system down. (Hint: it is.) By having this visualized, we can now start controlling the number of things that are happening at once and use our numbers to see if things are starting to speed up. 
• We might see patterns develop at different stages of work. One column may represent work done by another team, and so we are able to get a cycle time on that one column to find out how long the turnaround time is. This can help with predictability and planning.  
• There may be a discovery that shows an item refusing to move and no one knows what to do with it. From here, the team can determine whether the system needs to improve, the item cannot be done, the item is now irrelevant, or the item needs extra support to get moving.

Scrum or Kanban?

So, back to our original question: Scrum or Kanban?

As demonstrated above, the two are entirely different things, though they can exist in tandem with each other. For example, a Scrum team can create a Kanban board and use it to manage the work of their sprints, or a team practicing Kanban could decide to adopt the Scrum framework and apply it to the work they are already doing.  

And while both Scrum and Kanban reveal problems within an organization, Kanban can do it in a way that can be used seamlessly with any process, any framework, any organization, any person, any time, anywhere. Despite Scrum being an incredibly powerful framework, it brings with it a friction that can easily cannibalize the benefits it should provide.

For this reason, if an organization isn’t sure how to take the first step down the Agile path, Kanban is the easiest and most impactful one.