I have been taking a liking to Kanban a lot the last couple of years, it’s feels to me like a natural evolution for most Agile people from Scrum. Don’t get me wrong, I like Scrum, and I find a lot of it’s practices to be great. And in many contexts perfectly well functioning.
But the last 3 teams I have worked with wanted to try Kanban, or so they said… I think there’s some kind of picture in peoples minds about what Kanban means, and I have rarely seen a team claim to be doing Kanban who I would say actually is.
While that is a little hard to say, because Kanban is so light weight, it does have a few rules, and limit Work in Process is one of them. The problem I am finding is, teams don’t actually want to do Kanban, what they want is to stop estimating, and stop committing. I’m not even saying I have an issue with this, I feel estimating is a precarious activity at best, and a wasteful and destructive one at worst. I don’t have a problem with the concept of no longer committing to Sprints, I think a flow based work cycle feels a lot more natural. But I think what most teams think they are getting with Kanban is what many developers dream about. ”Just leave us alone, it will be done when it’s done”. To me, this is not at all what Kanban is about…
Kanban focuses very heavily on delivery, that’s what I like about it!
Kanban focuses very heavily on collaboration, that’s what I like about it!
But they are right about one thing, Kanban doesn’t focus on estimation, it focuses on Lead and Cycle time, which I personally think is a much more effective system of gaining predictability.
I wouldn’t really take issue with this, except that I worry there are many work places that are starting to think of Kanban as a bad thing, because there teams are not really practising Kanban. So, what kind of things do I see?
They generally don’t have WIP limits, or ignore them, which is essential to the success in Kanban. When you don’t use WIP limits, you lose almost all the value, you just end up with a lot of work started and nothing finished. There’s no drive to unblock tasks, just keep pulling stuff in.
They don’t measure they cycle time and lead time, so they cannot have any predictability, and the question ”When will it be done” is answered with ”shrug… we are using Kanban”. This makes it not very popular with managers you can imagine 😉 When we have reached stability in Kanban, that’s a question we should be able to answer very easily ”7-9 days” type of thing. Also, with no metric, it makes it very hard to gauge improvement.
They generally just have a board that says To Do -> Doing -> Done, which is fine if that is indeed how your process works, but it basically never is, this is actually something I see in Scrum teams a lot as well. The board is a visualisation of you’re process, and as such it should represent how things work, not how you want them to work, and not just so you have a to do list. If you can’t see where things flow out from the point of ”code committed” then you don’t actually have any idea how much WIP you have. Also, you need to understand the inflow into the team. I am huge fan of visualising the refinement process in Kanban.
The in and outflow are estential to success in Kanban. In order to get that predictability, you need to be able to have things arrive in a somewhat standard state, and have them leave with ease.
One of my favourite tools in Kanban or lean is the concept of explicit policies. Explicit policies are extremely helpful, not just in identifying discrepancies in the way the team works, but how to collaborate on fixing them.
So, a few quick thoughts on Kanban. You need WIP limits, otherwise you just have post-it notes on a wall.
You’re visualisation has to be representative of your process, otherwise, it’s just post it notes on a wall.
The other things can maybe wait a bit, but I think having a workshop about those early on is very valuable, and I will be doing a writeup soon about how I’ve started doing this.
I have several projects I organise in this way, running my company, the conference I organise, but those are a different context, and I don’t really need a Kanban approach in those projects.So, If you’re not doing this stuff, I don’t mind.
But please stop saying your doing Kanban and making organisations allergic to the word… It makes my job so much harder 😉