What is Best: Scrum or Kanban?

In his great article, Tomas Björkholm provides reasons for choosing Scrum and then for doing Kanban, as he puts himself in the position of a fan of each of these methodologies, giving objective reasons for liking or disliking any of them. He begins by quickly describing Scrum, as a method of splitting a project into small parts and working on them in set time iterations. There usually is also a team split involved (you're building small teams of people from across all company departments). Also, there is a Scrum board, easing the communication between the separate teams (visualizing what each of them is working on. Other characteristics involve writing Stories (general ideas behind a particular work item) and daily Stand-Ups (to discuss the work just done, in progress and any impediments).

Tomas then goes to characterize Kanban as the ultra simple Agile method, that can be summed-up by demanding from you to just visualize workflow and limit the work in progress. The main working feature of Kanban is the limits applied to how much work can be placed in particular lanes (so that the team's capacity is never overstretched).

We're also given a great summary on these two methodologies' similarities:

• emphasis on prioritization
• no need for the teams to be managed, as the board shows clearly all work progressed, upcoming and reviewed (great levels of transparency)
• ability to always improve the process
• appliance of the pull method
• improved communication and better co-working

Why Scrum is better than Kanban?

The reasons why you'd think so are: the fact that Scrum is run by iterations, so whatever you place in front of the team for a current sprint, they are committed to do, whereas in Kanban the process seems more of a constant stream of tasks to do. Tomas also sees estimates as value-adding, since they require the team to get to know what they'd be doing in the future better, which is already a saving on having to explain this later on. He also sees value in the fact that should there be any time left at the end of a sprint, it can be utilized to improve the development set-up in general, which will prove of value in the long run. There is also an undoubted plus in having the cross-departmental teams, this widens the spectrum of what the team is capable of.

Now why would Kanban be better than Scrum?

Björkholm appreciates the fact, that Kanban doesn't ask much from its users. The emphasis is on limiting work in progress and clear prioritization. Apart from this, there are the traditional Lean principles to follow and aim for achieving: high quality, continuous improvement, a "just in time approach to delivery and information flow, short lead time and reduction of waste.

Compared to Scrum, Kanban might be reducing waste in requiring no estimation (when something needs doing, it gets done, instead of being first estimated for). Another Kanban advantage is the ability for the team to work constantly, sprint or no sprint, the tasks gather in the backlog, ready to be pulled. Having specialized teams also benefits the overall process by making it easy to trouble shoot and communicate easily (as opposed to Scum's cross-functional teams). The lack of strict time commitment may save the team some frustration and stop the decrease of motivation, both quite often visible when doing Scrum. Tomas underlines the suitability of Kanban to teams, whose work is often disrupted and changed around (i.e. support teams). The limited Kanban constraints themselves are making it more flexible and therefore more easily applied to different kinds of work.

In conclusion

Tomas remains enthusiastic about both of these methodologies, his feeling is that the decision about which is better depends only on the particular situation and work type that you're about to do. Some types of work are best suited for Scrum, some will benefit form Kanban more. Test them for yourself and make your own decisions!

Read our article on Kanban vs Scrum »