Scrum and Kanban: Both the Same, Only Different

Liz's experience with Agile had started by working with a version of Extreme Programming (XP), very similar to Scrum, just not named as such. She had later familiarized herself with Kanban and grew knowledgeable in the Agile approach altogether. The aim of this article is a practical comparison of Scrum and Kanban, allowing people to get a better understanding of which methodology may suit their process better.

Issues with eXtreme Programming

The main differences in how Liz's team had worked with XP, are that they were having no commitments, but estimations and they didn't cross-function the team (the product development was owned by all in the team). The problem for them had been trying to polish up the cooperation, apply constant improvement and make the stakeholders accept the necessary risks associated with the process.

Scrum and Kanban similarities

• Centered around the team and collaboration.
• Focused on value, growth and fast delivery.
• Determined to stay flexible, take feedback and change the processes fast.
• Scrum was originally very prescriptive, but had recently become less strict and now allows more freedom.

Don't judge the book by its cover...

To a dilettante observer, who sees Scrum teams focusing on Scrum meetings, but using a visual board and observing Kanban teams do daily meetings and use visual boards with Kanban (signal) cards – there may not be much of an obvious difference. But, neither Scrum isn't about Scrum meetings, nor is Kanban about signal cards – their overall goals are different completely.

What do Kanban and Scrum concentrate on?

They both place value in workflow management. Scrum promotes collaboration as a means of reducing the amount of work. It utilizes measurement of velocity and uses estimations to keep the work in check. Kanban strictly limits the amount of Work-In-Progress (by numbers) and uses the Lead & Cycle Time metric to keep the delivery rates under control.

The differences

An important difference between the starting conditions. In order to implement Scrum, you need to begin by creating the right context and only on this basis set up the process, whereas to get going with Kanban all you're required to do is apply Kanban rules to your current, ongoing process. Another crucial difference is the alignment of the 2 methodologies' visual boards with what is really going on in the process. Scrum visualizes the way thighs should be processed ideally, and Kanban reflects the ongoing process exactly as it occurs.

Complex models promote interaction

Liz refers to the Cynefin model of looking at complex environments and brings up that it teaches, that the best way to allow the cause-and-effect rules of a system to emerge is to facilitate communication. Following this logic, as well as the ease with which Kanban can be applied to any process, it seems that Scrum is far less suitable to many a team. Teams who are distributed and cross-functional will have a hard time maximizing the cooperative and interactive opportunities, whereas the same teams will work fine with the less restrictive Kanban.

All in all, Kanban finds application in far more business operations, and Scrum stays limited to a certain working model (one function team in a closed environment). This is why Liz, along with many other Agilists, are turning towards Kanban rather than sticking with Scrum.

Read our article on Scrumban - the great solution for teams, that outgrew Scrum »