Understanding the Kanban for Scrum Teams Guide

The major one we’re getting comes from people who are experienced Kanban practitioners who notice that how we describe Kanban in the Kanban Guide for Scrum Teams is different than the definition they’re familiar with. (Including my Kanban Primer for Scrum Teams blog post for example…) This isn’t an oversight. It’s by design. When we set out to create the Kanban Guide for Scrum Teams/approach, we had a specific context in mind. In that context, teams use Scrum according to the Scrum guide, ideally professionally.

The Kanban Guide for Scrum Teams focuses on helping in this context. These teams already have a collaborative inspect and adapt experimentation process and a set of explicit feedback loops they’re using. So, we set out to define the minimal most straightforward set of Kanban practices that these Scrum teams would need to add to achieve steadier, healthier, more sustainable flow (I like to say it is like moving from a sprint that looks like a swamp to one that looks like a river).

After some discussion, we decided that these practices complement what a professional Scrum team is already doing :

· Visualization of the workflow

· Limiting WIP

· Active management of work items in progress

· Inspecting and adapting their definition of “Workflow”

While we agree with the importance of “Improve Collaboratively (Using models and the scientific method” and “Implement feedback loops,” we think they are redundant in a professional Scrum context.

They’re not part of the guide because we don’t consider them part of the “minimally viable set of practices” a Scrum team should focus on when trying to improve their flow. Having said that, our guide, and especially the PSK class, provides people with some pointers towards advanced complementary Kanban/flow practices/metrics that at least some can use to continue their learning and improvement journey.

Beyond that , some of them might be useful in some Scrum contexts, and some might not.

In my personal view, it is pretty close, as long as you assume professional scrum is your starting point. (see a blog post I wrote in 2012 about this context). You are starting with how the team uses Scrum and respecting their current Scrum process & roles. You are interested in pursuing an incremental, evolutionary change to improve your performance and satisfaction with your process beyond what you currently achieve with Scrum.

There is an argument that limiting your work in process is not an evolutionary change but a disruptive revolution. My personal take on it is that, yes, limiting your work in process and moving to a disciplined pull mode is far from being easy, but it’s still evolutionary compared to changing team structures, roles, and process flows. In any case, this is an argument about the Kanban Method outside of a Scrum context. A professional Scrum team should have an easier time limiting WIP than most.

It depends on who you ask. Some people define ScrumBan as ” a way to help teams transition from Scrum to Kanban.” This isn’t what we’re talking about here.

Another definition (that I subscribe to) is to see ScrumBan as a way to introduce Lean/Kanban flow into a Scrum context  while keeping the core Scrum process intact. This is pretty similar to our take on the process Scrum teams will typically take to achieve an effective combination of Scrum and Kanban.

Finally, a variant on this definition is to see ScrumBan as simply the Scrum+Kanban combination itself, without worrying about your starting point and journey. In my view, this is what the Kanban Guide for Scrum Teams describes.

The last question I want to tackle is one of the first you might want to consider. Essentially, the question is, “Why bother? Isn’t Scrum great as is?”

Most teams I’ve worked with since 2010 or so find Scrum+Kanban to be the ideal mix. I’ve helped Scrum teams achieve an even healthier, smoother flow by adding Kanban to their process. I’ve helped Kanban teams accelerate their pace of improvement by adding cadence/rhythm and clarity. I’ve helped teams look beyond their Sprint at the end-to-end flow from idea to outcomes using a Kanban system. I’ve helped organizations manage the flow across several Scrum teams using a Kanban system.

When a Scrum team wants my opinion on whether adding Kanban would be a good idea, I typically ask them to think about how hard it is for them to Sprint and whether they feel like they have a good flow during the Sprint. (And like I mentioned above — do they feel like their process is a swamp or a river). It’s as simple as that. I find most Scrum teams struggle to achieve good, sustainable, healthy flow, and Kanban tends to help them with that.

Some Professional Scrum Trainers asked, “When would it be a bad idea to introduce Kanban to your Scrum? What indicators suggest you stop using Kanban as part of your Scrum?” I can’t think of any team where I felt they should stop using Kanban. If they understand Kanban and do it well, there’s really little that can go wrong. The problems start when they don’t understand Kanban or use it as an escape from the challenges of Scrum. Yes, Kanban can help you make your Scrum more sustainable and healthy, but please don’t add Kanban if you want to escape the difficulties. Kanban, done well, adds discipline to your Scrum.

Another bad time to introduce Kanban is when the team isn’t looking to improve. If things are working well or, more importantly, if the team perceives things as working well, they won’t have the energy needed to add Kanban to their process successfully. So make sure you agree on pains/motivations before you move forward to implementing something like Kanban.

To finish with scenarios where introducing Kanban IS a great idea . It pains me every time I see a team/company using Scrum as a new variant of “project management command and control,” focusing more on tasks, story points, velocity, and burndown than on empiricism leveraging Done Increments of potentially releasable product.

What I’ve noticed is that introducing Kanban ideas helps these teams/companies finally understand Scrum. They shed a lot of the unnecessary and even harmful baggage and instead refocus on the transparency, inspection, and adaptation brought to life by the core Scrum events, roles, and artifacts. Pretty amazing, isn’t it?

This blog was originally posted on Scrum.org

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.