Agile #2 – Kanban vs Scrum – Myths and Truths

After an introduction on Kanban, in this second article I will try to make some evaluation of Kanban, taking Scrum as reference which is a methodology I consider myself experienced. I want also to emerge some myths and truths that are flying around. Personally I have been using Scrum for almost three years in the same project (in a definitevly non-agile organization – with all the difficulties implied). in 2011 I became Scrum Master certified.

Before start reading, be aware that this article doesn’t aim to support one or another agile methodology. I’d like to share some thoughts coming from my experience.

Let’s talk about Scrum. From Wikipedia: Scrum is an iterative and incremental agile software development method for managing software projects and product or application development. Scrum has not only reinforced the interest in project management, but also challenged the conventional ideas about such management. Scrum focuses on project management institutions where it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loops that constitute the core management technique are used as opposed to traditional command-and-control oriented management. It represents a radically new approach for planning and managing projects, bringing decision-making authority to the level of operation properties and certainties.”

Scrum methodology

Scrum also define three main roles: Team, Scrum Master, Product Owner with different responsibilities and duties. If you want to know more about Scrum this page contains good description and explanation.

Kanban and Scrum, two different models, two different origin, a common goal: deliver business value.

To achieve the same goal, Kanban and Scrum use different approaches, and they can be effective on different contextes. Let’s see some myths and truth about my experience with Scrum and Kanban:

Myth #1: ${methodology} gives better visualization of the workflow and the problems can be better identified. This is not true, if the problems are not visible on the board means the board is not correctly designed. Change the board instead (e.g. add more columns).

Myth #2Scrum is harder to adopt, because has more rules and is more restrictive, Kanban is easier and can be adopted step by step. Indeed Scrum has more rules, but nobody stops you to adopt Scrum gradually or only partially. For example you could start having stand-up meetings every day. Adopting the full implementation of Scrum require just a bit more training than Kanban.

Myth #3Repeated daily meetings are part of the waste generated due to communication overhead. I think in every environment the communication is one of the failure point. The benefit of having daily short meetings is enforce everybody to be informed about what is going on in the team. Believe me, desk-mate sometimes are not talking. 15 minutes must be the maximum time for a stand up meeting for a 7/8 team’s people.

Truth #1Kanban works better in a maintenance team. In maintenance mode, the team has to guarantee a constant lead-time (time from when the ticket is open to when is closed). The input throughput is not predictable and is subject to high variability. The focus is not the delivery before a certain date (end of the iteration) on tasks coming with variability therefore Kanban is surely a better choice.

Truth #2: Scrum works better in a development team. Where the focus is to delivery incremental features within sprint boundaries, Scrum gives to the team better visualization of the short-term and final goal. Kanban has the concept of fixed delivery date, and can be adapted, but Scrum comes naturally as the best choice for this case.

We can stay talk for hours to see the differences, but the real truth is that both can be adapted to basically any kind of situation. The real problem is not the method itself but the maturity of the organization. That’s the crucial point! Maturity of the organization doesn’t mean only maturity of the management, but also maturity of external teams, procurement, test teams, etc however most of the big organizations are still behind the schedule, and they are starting slowly to move out from the old waterfall approaches.

For sleepless nights: Scrum vs Kanban:  is an interesting book, written by Henrik Kniberg that explain how Scrum and Kanban are related and can be used together.


3 thoughts on “Agile #2 – Kanban vs Scrum – Myths and Truths

  1. You should try using scum and Kanban together on software development teams. It’s a brilliant combination that resolves many of the weaknesses of Scrum.

  2. Murray, indeed the methodology needs to be adapted, but what do you mean with ‘use them together’? What would you use from Kanban and what would you use from Scrum? and what weakness of Scrum would solve?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s