When I first heard something about Kanban several years ago I did not like it at all. Working as a passionate ScrumMaster with a team following good Scrum practices, I was very suspicious about it. The first thing I’ve learned about Kanban was that there are no sprints and there is no commitment and it sounded horrible to me. I just could not imagine that a team will aim for high performance without giving a commitment to the Product Owner and to themselves.
In the last two years I had a lot of touching points with Kanban. I listened to talks, read books, drank coffee with Kanban enthusiasts and finally even worked with several teams making use of Kanban implementations. My perceptions about the usefulness of Kanban in software product development changed completely. Nowadays I would not want to set up a Scrum team without making use of the principles and practices of Kanban. Otherwise I would not set up a Kanban team without using some of the Scrum ceremonies like retrospectives or daily stand ups.
I know ScrumMasters who are still very suspicious about Kanban and only think of it as being Scrum without commitments. If you are one of them, I want to give you a brief list of things Kanban can do for you to make your Scrum better.
A Scrum team is self organized. That means after pulling a set of stories into the sprint or after committing onto a sprint goal, they can do whatever they want to have a successful sprint. Kanban has practices for your team to manage their work flow from generating ideas to delivering product increments to customers. It gives your team good guidance on how to use the freedom of self-organization successfully by explicitly visualizing the complete work flow and limiting work-in-progress for instance.
More to see
When set up properly you as a ScrumMaster will be able to learn more things about your team using several metrics and charts of Kanban. Those will add to your Scrum toolbox and your ScrumMaster’s intuition to evaluate the fitness of your team and to guide them to become better.
There are retrospectives in Scrum. And your team is expected to use them as learning opportunities and to commit to improvements. Kanban in addition wants you to set expectations for each change your team commits to do and later on asses if your change was successful or not. By using learning models like the Deming cycle for instance Kanban shows you how to evaluate you improvement ideas in a complex environment and how to keep track of them.
Greater adaptability if needed
I love Scrum and I believe it is the best fitting framework for many software development teams working on innovative products. But Scrum is also very strict about many things, like its roles and ceremonies. It even expects me as the ScrumMaster to defend it against framework changes. This will sometimes put you as a ScrumMaster into the very uncomfortable situation to foster the team’s self-organization but not allowing your team to modify Scrum to their individual needs.
Kanban gives you a broader perspective. It helps you to see your team from a systems thinking point of view and encourages you to continuously change your process as long as there are sources of dissatisfaction left. Kanban helps you to let go and even to encourage your team to modify their process beyond the borders of Scrum if it increases their business agility. The evolutionary change that Kanban fosters will help you control the risks involved when crossing “safe Scrum borders”.
Less resistance to change
If you want to successfully change how people work you need their acceptance and trust. Many teams which are confronted with Scrum for the first time perceive it as a big revolution. It might initially scare them so much that they don’t even want to start changing at all and even if they start it might take a long time until they really see and feel the benefits.
Kanban encourages you to start with your team right where they are and even accept all roles, job titles and responsibilities. From that starting point you will change continuously and step by step. Most of the time it is much easier for others to follow your change management that way.
From my perception scaling a Kanban system is a very straightforward process, though it might not be easy in terms of getting more teams, departments and management into the system. Starting with the visualized flow of your team you can scale out by taking into account what is happening with the things your team builds and where does all this work for your team come from. You grow your Kanban and integrate more and more of the complete value stream.
By following the same principles and practices you can also manage the flow of many teams, departments or the whole organization as you do with Portfolio Kanban. You just have to choose the appropriate granularity for the work items on your board.
For me there is absolutely no Scrum vs. Kanban question. I see both of them acting in different dimensions and helping each other just the same way I would encourage my Scrum team to make use of XP practices like TDD or pair programming. Kanban made my Scrum better, I believe it will improve yours to.