Scrum vs. Kanban - When Is Which More Suitable?

If you've just got on the road to Agile, having concluded that the current organization of your processes is inefficient, this is the perfect moment to consider going Agile.

Agile does bring a change about

The change will not go without notice, both from the team's and manger's point of view. It's quite different working along with an Agile methodology than with a traditional process. The new elements for the team to get used to are: iterations, daily meetings, regular reviews, cross-functioning the working teams, appointing roles (i.e. product owner, scrum master). The changes visible for the manager include higher flexibility associated with short sprints and therefore better ability to plan the long term development, a change of old unproductive habits and – given a little time – higher productivity.

A forced change can motivate an evolutionary change

Thanks to Scrum asking the team for commitment (in Sprint planning), they need to consider what they can and should achieve in a given time. This promotes a way of thinking, which can result in reconsidering how much is being done and how speedily. Very often, when teams are asked to commit to delivering something, the managers are surprised with how much the employees actually hope to achieve – often more than the manager would have demanded. This way the team gets a work ownership attitude – they take what they've committed to more seriously and with deeper engagement.

How does Kanban fit into this?

When compared to Scrum, Kanban is far less restrictive and not as structured, it tends to more be driving an incremental change rather than apply it right away. As a great advantage over other Agile methods – it can be applied to any process, in its given state, without having to begin by making changes.

How does Kanban work?

In Kanban work gets visualized on a board, which is divided to columns in a way that reflects the process stages. As the task gets from one stage to another, the card should be moved to an appropriate stage, to represent the progress of the work. For instance, you may have stage columns that include: backlog, requirements gathering, development, testing, quality check, deployed and done.

WIP limits

The important thing to remember when implementing Kanban is the all-important Work-In-Progress limit. This is how a Kanban board differs from any other visual board – the amount of work that can be progressed at any time is restricted, therefore any wasteful multi-tasking is eliminated and focus on the work being done can grow. Thanks to applying the WIP limits there is a lot of emphasis placed onto finishing the once started work, rather than starting new work all the time. Also, by limiting how many cards can enter a certain stage at any time allows the team to identify any bottlenecks and attempt to remove them. This is the simple way in which Kanban becomes a change agent in any organization.

Scrum or Kanban?

According to the information above, the choice of an appropriate methodology might depend on the situation in which the team is. If the problems run deep and they've agreed that a current process doesn't work, it would make more sense to make a radical change and go for Scrum. But if your organizational process works partially and you simply want to perfect it, making a smooth change over to Kanban will be more sensible and promising.

Read a thorough comparison of Scrum and Kanban »