Sharing thoughts and experience about Agile, leadership and organizational change

Kanban – What’s in for you as a ScrumMaster?

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.

Flow management

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.

Experimental learning

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.

Scalability

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.

Post navigation

6 thoughts on “Kanban – What’s in for you as a ScrumMaster?”

Thank you for an excellent write-up and for your perspective as a Scrum Master and leader of a Scrum team. I have been looking for such detailed and explicit reasons for why Scrum teams should consider Kanban – and your analysis is perfect for me. And I really liked the last sentence – that there is “absolutely no Scrum vs. Kanban question”! Too many poorly written articles out there compare – and wittingly or unwittingly – pitch these two methods against each other, to the great detriment of great teams writing great software!

Hi, there is no commitment in Scrum anymore either, which is a good thing. It was always misunderstood anyway, and never really meant what most people mean by commitment. Best to keep everything as a “real option” until it is basically delivered. Oh and Kanban actually does have commitment. It actually has an optional two-stage commitment approach. The “lead time timer” starts when commitment is made between the system and the customer to begin work on something. A second commitment can be made after the majority of work is completed, a commitment to deliver the work with a higher degree of delivery date certainty.