I’ve had quite a few clients over the years who have wanted to adopt Kanban as their agile process. For some of them, using it is absolutely the right choice. For many, though, their desire masks some fundamental “agile mindset” issues and Kanban is not what I recommended, much to their disappointment. The reason is because there are some considerations before you adopt Kanban.
Kanban Review
Before we jump into what to be wary of when adopting Kanban, let’s talk about what it is. describes it as:
[A]n approach to process change for organizations which uses visualization with a kanban board, allowing a better understanding of work and workflow. It advises limiting work in progress, which reduces waste from multitasking and context switching, exposes operational problems and stimulates collaboration to improve the system.
You’ll see that at no point is it described as a “process”. It’s an approach to process change, or, as I like to think of it, a lens through which you view your process. It works with whatever process you have but doesn’t replace it. If your process isn’t already agile, adopting Kanban won’t make it agile.
Kanban and Agile
I’ve spoken with many clients who want to adopt Kanban. And I can tell that it’s being driven because they think that it is lightweight. That it lets them keep their existing processes. And that it allows them to claim that they’re “agile” to their managers. And, other than that last one, they’re pretty correct. But they’re also wrong.
As we learned above, Kanban isn’t a process. You could put Kanban onto your waterfall process- that doesn’t make waterfall agile anymore than it makes it a penguin (much like that guy). What it will do is show you how work flows through your team so you can manage and improve that flow. Any process that follows the is agile; if your process does, it is.
Kanban Considerations
When clients ask me to teach their teams Kanban, I want to find the core reason “why”. Is it because they have some personal goal just to make their teams “agile”? If so, I tend to advise against it. My experience is that teams using Kanban need even more discipline than teams using another framework, like (which is what I usually recommend to those clients). Kanban can show you where you’re falling down in your process, but it’s up to you to understand how to make improvements.
I generally view these teams as great candidates for Kanban:
- Production support teams
- High-performing agile teams
And that’s it. That may be shockingly small, but let me explain why.
Production Support Teams
I’ve worked with quite a few teams that had new development responsibilities but still had to support production systems. Sometimes that support work was negligible and sometimes it totally disrupted their sprint plans. When you plan a sprint and find you can’t do any of the committed work because you’re fighting fires, that’s demoralizing. It also makes achieving one of our goals in agile – predictability – almost impossible.
These teams can really benefit from restructuring the flow of their framework. For my teams, they were using Scrum and then blended it with Kanban (also called in some circles). This blending allows them to visualize their work while highlighting their impediments and their critical items. And using the right metrics allows them to understand their flow, or how work moves through the team. How quickly are they addressing critical support issues? How quickly does new work move through their queue? How much – of each – are they delivering every week? Armed with this knowledge, teams can start making improvements. Otherwise, they tend to flail.
High-Performing Agile Teams
My other prime candidate for Kanban are high-performing agile teams. “Why,” you may ask, “would we change how a high-performing team works?” Because sometimes their framework can get in their way. A great example is a team I worked with that was executing on work in Scrum amazingly well. Their ceremonies were quick and efficient. The Scrum Master was finding it hard to come up with new ways to challenge them. How else could they improve? The answer, of course, was Kanban.
This team opted to move toward Kanban and deprecated some of their ceremonies. Not because they didn’t want to do them, but because they were operating together so effectively that the ceremonies were getting in their way. They were dragging the team down. They still did the activities usually occurring during those ceremonies, but just in the course of their daily work.
@ Velocity
Our teams focus on integrating with our clients’ processes, so we are able to adopt whatever process our client uses. That said, if a client is using Kanban as their “agile process”, they’re setting us – and themselves – up to fail in some way. As the Agile Evangelist, I can step in and help coach our teams and our client on the best ways to make a Kanban adoption successful. It’s part of why I love my role – I want to see everyone succeed. We love Kanban, but we want to make sure we’re doing it the right way.
Final Thoughts
Kanban is a wonderful addition to any agile process, but it requires some level of explicit discipline that is implicit in other frameworks. And it’s not a process in and of itself – it’s complementary to whatever process you’re already using. Keeping that in mind and keeping the goal in mind, Kanban can help your teams soar.
Buena suerte, mis amigos!
Bill.