Kanban has come of age and what that means is that there are now just as many (maybe more) misinterpretations of it than ever before. I've seen this happen when XP, Scrum and Lean became popular - so this is no surprise. There are some differences, however. With Kanban, there are thought leaders, such as myself, who are willing to say what Kanban is and not just say "it's what you do after you understand it." While Kanban isn't a thing actually, it is somewhat well-defined and it is easy to tell if many of the things said about it are true. Here are some of the most common mis-interpretations I've heard.
Lean is not at all prescriptive. Lean is about thinking. Yes, it does suggest you should always attend to time and make sure you are not overloading teams. But how you do it depends on the context of the problem. Lean is about learning – not acting without thought. See my blog Rethinking the Practices of Scrum – or What Would Chris Alexander Say? for more.
Lean manufacturing may assume linear work, but not Lean software development (nor Kanban). Kanban boards may often appear to be linear but Kanban boards reflect the way people are doing the work. Hence, if people are working linearly, the board will reflect that. However, Kanban boards can also reflect non-linear work. One must also recognize that a Kanban board does not reflect the people doing the work but rather reflects the flow of the work being done. Hence if a board looks like:
it is not suggesting that the work be done by different people and hand things off. It just shows the states the work progresses through. In this case, it's on the backlog, in analysis, being designed, coded, tested or completed. It could very well be the same person doing the work. The second misconception is that the board tells you to break things down into these steps. Actually, it doesn't (or shouldn't). The board should be a reflection of the work being done. So different columns on the board should reflect the different steps the team is doing. If the team swarms on multiple steps, then the Kanban board should only have one column for that. Essentially the Kanban board has one column for each type of work the team is doing. The explicit policy for how it gets to that step and out of that step also needs to be stated, but is not necessarily written on the board. Bottom line - if you don't like the process that you see on the board, change it (and then update the board). The board is there merely to reflect on your work so you can better change how you work.
A Kanban board reflects the process that the team has stated that they follow. It is not something to be followed, but rather reflects what the team is doing. It is not meant to be static. If the team sees a better way to do the work, they should change their policy. An explicit policy can also have options to it. You can say "Under these circumstances, we do this. But if we have this, do that. ..." Being explicit does not limit what the policies you have can be. It just means they've been communicated from one team member to another.
The following is an excerpt from my blog David Anderson's Kanban Book and the Myth of Early Adopters:
In the last few months, I've heard several people say Kanban's success is because it is early adopters who are applying it. I actually believe just the opposite is true. While Net Objectives consultants may be considered "early adopters" (we are always looking for the next best thing to offer our clients) most of the teams that have adopted Kanban or Scrumban are actually late adopters. That is, they have gone from non-agile or some kind of generic agile to Kanban/Scrumban. The reason is that they couldn't see how Scrum could work. Or, the teams weren't excited about doing Scrum.
Given that Scrum has a limited context in which it works without major disruption to an organization, this should not be surprising. Yes, I know Scrum is supposed to make impediments visible and have the company remove them. But making impediments painful is not the only way to make improvement in one's process.
Over the last couple of years, I've seen three groups for which Kanban is particularly useful:
Kanban is useful for these three groups for different reasons. Respectively:
It is interesting to note that the last two groups are often late adopters to Agile. For those having people with specialized skills, they've often avoided Agile because they don't see how Scrum or XP can work (neither can I, BTW). In the second, they don't want to try such a deep dive into a new method.
I think much of the reason Kanban has been successful is not because it has been adopted by early adopters, but rather because it was designed for late adopters (that is, those afraid of change). The fact is that many of the success stories of Kanban are now coming from late adopters of Agile – saying otherwise is merely marketing obfuscation. Kanban works not because who is adopting it, but because it was designed to be adopted in an incremental (dare I say, Agile) manner. Scrum, on the other hand, is a "jump in the water (may or may not be) fine." Kanban works because it truly manifests the principles of agility – respect people. Let them use what they know and let them turn up the volume, so to speak, of agility at their own pace. Don't force them into it because they'll know that's the right approach after they've done it. In other words, Kanban consultants tell their charges – "trust yourselves, don't trust us."
I have no idea where this comes from other than perhaps marketing hype. I don't know of any Kanban thought leader who has ever said this. There are times you want to start with Scrum, but there are times you want to start with a flow based method. It depends on several factors. Scrum is fine to start with if you either already have well-defined teams, or can easily get thm formed. Kanban is designed to start where you are so if you don't have well-defined teams and they'll be hard to form, I'd start with Kanban. Even if you have teams, but work on mostly small items or if there is some resistance to Agile methods, I'd still start with Kanban. For more information on which one to start with, look at one of webinars on different factors of this decision in our Business Driven Software Development. Session 3 is Where to Start Your Agile Transition while Session 4 is Team Agility: Scrum or Kanban? My own experience is that Kanban is easier to start with than Scrum, but that doesn't mean it is always the best place to start either.
Kanban is based on Lean thinking. One of the pillars of Lean is Deming's respect people while looking to create an environment (system) for them to be productive in. I believe this misunderstanding comes about because Kanban talks about the work not the people – but this does not mean that we don't respect the people. Rather, its focus is on creating an environment that will facilitate the emergence of productive behavior. In many ways, this is more respectful than merely cheering people on. Kanban lets you start where you are with the roles you currently have. You don't need to say – "we're going to learn a new method where we will reorganize our teams, adopt new roles and rules." If you ask me, that's telling people they've been doing it the wrong way – which doesn't sound too respectful to me.
You can't really get people to do what you or they would like to do by just telling them to do it. People know what to do, they don't do what they know. You must create an environment within which they can work better. Focusing on the environment may not look like it is about the people, but it is. Kanban helps people by providing them with the tools (e.g., Kanban board) that create what the people need to know to get their job done (e.g., visibility of the work flow).
Kanban believes in evolutionary change. The reason is so you don't overwhelm people with too much change. Traditional Agile methods may believe in dramatic changes, but that's difficult to do beyond the team level. Kanban enables the organization to change at the rate it can bear. The ability for a method to make significant change in an evolutionary way is revolutionary. When you stop to think about it, you'll actually realize that evolutionary change is about starting a method that will sustain itself and keep growing. This is what a learning organization truly is – being evolutionary over time to become revolutionary.
You can check out Net Objectives' resources.
If you are interested in training in Kanban, please send a note to Mike Shalloway – mike.shalloway @ netobjectives.com
If you'd like to follow my Lean-Kanban-Scrum ramblings, please follow me on twitter @alshalloway
If you'd like me to discuss more myths of Kanban, please loot at our Myths of Kanban Poll and respond.
Here are some other blogs you might find of interest: