Kanban vs Scrum: How to Make the Most of Both

This insightful book begins by stating the basic characteristics, differences and relations between Kanban and Scrum. It explains how Scrum teams work in time iterations, focusing on small tasks created from larger jobs, set on a WIP limit for the entire Sprint (iteration). In comparison, Kanban places importance on visualization of the workflow and limiting the Work In Progress for any given time (number of tasks per team member or per team).

The general differences

With regards to these methods in relation to each other, Kniberg and Skarin underline the fact, that they cannot necessarily be compared to each other, as they often serve different kinds of work. But in general, it's known, that Scrum puts a lot more restrictions on the workflow, whereas Kanban allows flexibility and focuses on making improvements possible. Scrum assigns roles, demands time-boxed iterations, Kanban supports an ongoing flow of tasks. Both the methodologies base future improvements on analysis of the past experience.

Scrum is closed while Kanban stays open to change

The main difference is the Scrum's resistance to change during an iteration and Kanban's openness to alteration any time. Another distinct difference is the fact that a Scrum board gets reset after each iteration and Kanban can go on, since the backlog is constantly refilled. Also, Scrum asks for our team to split into multi-functional smaller groups and demands project completion estimates - none of which are necessary in Kanban.

The general similarities

As to Scrum - Kanban similarities: they both are Lean and Agile and both facilitate processing multiple projects at the same time. The authors of the book encourage us not to limit ourselves to just one methodology, suggesting that Scrumban might be the way to go for many teams. They also provide some real-life examples of Agile boards and give useful advice on how to make a start on going Agile.

Conclusion

Their final take-away points are to never stop retrospection, in order to learn from your experience and to keep experimenting, as you never know what possible solution may turn out to be the best for you.

Read our comparison of Scrum and Kanban »