An interesting comment from Rob Bowley to my “Hardest part of Agile” blog entry. Rob asked “A lot of this discussion around Lean and Kanban Software Development seems complicated and is getting quite scientific. Does that mean it’s probably not agile?”
Lets try and answer that.
When I have introduced Kanban to teams I’ve actually found it easier to get the team started on Kanban than other Agile approaches. I definately think it is easier to get started with Kanban than say Scrum.
I say this because Scrum asks you adopt Scrum perfectly before you change it. Even if you don’t adopt Scrum perfectly you need to make a lot of changes to get close to Scrum. Many teams which claim to be doing Scrum would not pass the Nokia test or any checklist of Scrum practices.
Kanban on the other hand isn’t so much a software development method but a method for process improvement. When I introduce Kanban I start by mapping out the teams process and using that to create a Kanban board. The Kanban board shows were the issues are and we work to improve them.
Why Kanban sounds so difficult is because is because people are still working out why it works, what works best and how to implement it. You need this kind of understanding to validate the approach and to apply it widely. But most people don’t. They can delve into the Kanban toolbox as and when they need to.
For example: visualizing the process on the board will help you improve flow. You don’t need to know the word flow or what’s behind it.
But, and this is the big But with Kanban, and its my big fear with it….
Kanban can be badly or poorly applied even more easily than Scrum. You do need someone on the team, or available to the team, to get the process improvement process going. It is easy to map out the board and leave it at that. Getting the process improvement bit going is the difficult bit. Whether you are doing Scrum, Kanban or anything else creating a culture of improvement is hard.
And a Kanban board shows up your problems more quickly than anything else. Which means things might look like trouble very quickly. If you don’t have someone who knows what the board is telling you, and someone who can help the team address the core problems then it can look scary.
So even more than Scrum I advise Kanban teams to have a coach. Someone who’s been there before and someone who can drive team based improvement.
Back Rob’s question. “Is Kanban Agile?”. Well hopefully I’ve explained why it is simple enough to be considered Agile so on that basis I think it is. Whether the Kanban folk want it to be considered Agile is another question. I think many of them would prefer it was considered Lean not Agile.
As I’ve said before, I consider Agile to be a form of Lean or even exactly the same (see Agile and Lean – the same but different). Kanban’s roots are more clearly in Lean than other Agile methods. I also wonder if we would have had Kanban without 10 years of learning from XP, Scrum, etc. So Kanban might be the first “post Agile” method, thats why I put it on the side of my triangle:
See Agile and Lean – the same but different for an explanation of the triangle.