In my last post I made a point that Scrum contains Kanban. So let’s look at it from another angle. Let’s see what is the most important aspect Scrum provides and which is missing in Kanban. It’s not about specific roles or meetings. It’s not even about iterations. It’s the purpose driven aspect. In Scrum, we build a Product Backlog, which shall be ordered by business value. It is not meant to be any todo requirement list. It’s a tool which allows us to split the tiny most important vertical slice of functionality, deliver it and get fast feedback from customers.
Product Backlog needs very strong foundation, otherwise the prioritization gets hard or even impossible and you are back at reactive mode we tried to avoid. In Scrum, we want to form a strong clear product vision, and then talk about what we shall deliver next Sprint and form it as a Sprint vision called ‘Sprint Goal’. Only after that we can talk about which items we shall have in our Sprint Backlog.
Kanban, on the other hand, is great for reactive type of work like call center for example. In call center we don’t prioritize up front, we don’t plan big. We only need to visualize our process and improve its overall quality. For such environments Kanban is great match and it is a good idea to use it.
Learn more about transforming organizations, leadership, and culture with Agile & Enterprise Coaching. Check our Scrum and Agile training sessions on Sochova.com. Grab a copy of The Great ScrumMaster: #ScrumMasterWay book and The Agile Leader: Leveraging the Power of Influence book.
Disclaimer: All I write on this blog is purely personal and has no relation with any position I have, used to have or will have in the future.
My impression is that there is very little difference between an optimal Scrum implementation and a mature Kanban implementation (at the team level).
What Kanban has which Scrum doesn’t is a built-in mechanism for scaling to the enterprise level, and complete freedom to change anything about it that improves the delivery of value. If a Kanban team finds value delivery suffering from the lack of a backlog, then can experiment with adding a backlog. If a Scrum team questions the value of a backlog, they can’t experiment with doing away with it and still claim to be doing Scrum properly.
Yes, Kanban makes Scaling very simple task, that’s good point 🙂 however it doesn’t make it easy to apply I guess, right?
I also agree that if well done – there should not be any big difference in good Kanban and good Scrum…. Having said that… I’m back at my original thought (not described in this blog) that Agile and Lean are like twins. Looks bit different but in reality very same. 🙂
Thanks for your thoughts.