Calling it Kanban

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.

Example: https://leanpub.com/actionableagiletools/read#leanpub-auto-visualised-flow

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 😉

Annonser

The Product Vision

telescope-122960_1920

Since I wrote the last post – about the ever so common product owner-team gap – I’ve been considering the issue and how to solve it, from what seems to be every angle.

Perhaps the solution is simply, as I stated in the original article, to point out the problem to the involved parties, and make them work on closing the gap by approaching their counterpart. But recently, I’ve come to the conclusion that there might be another problem, just beneath the surface.

When analyzing the problem more closely, the true issue is almost never that there is a gap between the product owner and the team. Instead, the problem is that the product owner and the team does not share a common vision of the product.

The product vision is a goal, a common idea, of what the product will be in the future. It might exist in the form of a prototype, design sketches, requirement documents or (perhaps more common) simply as a more or less vague idea in the mind of the product owner. Now, if the team does not understand, or share, this product vision with the product owner, it is not that strange if the gap occurs. The product owner and the team will inevitable talk about different things, mean different things, because they have have no common ground. So, the first step is thus to establish such a common ground. One way of doing this, is to simply gather the team and the product owner in a room, and workshop until a common understanding of the product vision is reached.

Now, what I have found is that the much more common reason for the product owner gap, is that there is no product vision.  There might several reasons for this, but the most common one is that the product owner considers the needs of the stake holders, but does not consider how the changes will work together as a whole. This is, instead, left to the team to figure out. While this might work with a brilliant, dedicated team, it is almost assured that this will fail with a team in a startup phase, or a team that is suffering from some dysfunction.

In this case, it is important for everyone to understand that there will be no great product, unless there is a product vision. Be it implicit or explicit – it must exist – how else can the product owner assure that the right stuff is being built?

Do you recognize this pattern? Please let me know in the comments.