2 July 2012

Re: Are the Kanban practices in the right order

The Juggler's Assistant By Pryere, @Flickr

[Edited after some feedback from David Anderson and Kurt Hausler]

First read
Haken led a discussion at the recent #klrat meetup where the participants discussed the order of Kanban implementations and the depth of application. Sequence, avoiding maturity models and spider maps were all discussed. I wasn't there and the blog post probably on skims the content.

Jason takes the conversation and reflects on the order of adoption of the Kanban method practices and discussed the order he approaches people and teams with the techniques.  There is a thing here where, like scrum, applying the whole system lead to exponentially increased benefits, but the focus of Jason's and this blog post is on the introduction phase of Kanban practices.

My experience usually Jason's, but I also have exceptions I can point to.

In summary Hakan and Jason's variation from David Anderson's model is that you are more likely to make policies explicit before you get around to address WIP limits. Both of the blog posts above provide a good -and concise- explanation of the variance in their (and my) experience.

I also think limiting WIP has a bigger pay-off than explicit policies. At least it has in my experience.  And there is a likely scenario where you will go to limiting WIP before explicit policies. Here is my thinking, based upon my experience and observations;

Typically, acknowledge the current situation before improving
Typically in an enterprise we are conditioned to expect and work with defined processes and standards. In my work I have often invested a good amount of work in stripping away process and standards to free up the team to do the work.  When I do this everyone gets nervous, especially the people who are now accountable and responsible for the outcomes of the work.

Process is like a blanket on a cold winter day. (Hello Melbourne!) It protects you from the elements.  "I was just following process!" is a legitimate excuse for shipping shoddy product on time. Or even late. But when the safety blanket is removed people need to take action and make sure they are actually doing something valuable. Mindfulness becomes a responsibility the staff member can't shirk.

In this context explicit policies feel like process. They give some comfort that the team members are not being offered up as sacrifices to the elements. 

And in this context you are almost trading "visualising the work and flow" which gives us all understanding and transparency, for explicit policies for the team's sake. The team then get to explain the current mess by observing the polices that enabled it to emerge.  The team can then get on with the business of improving without having to deal with any blame or guilt that might be a legacy of their past.

There is also the culture of busyness, and it is a hard nut to crack, so it is sometimes easier to deal with things that are simpler to execute than trying to break entrained thinking and behaviours. Frankly despite the learning games, and general acknowledgement that "we are all trying to do too much" people find it really hard to break their habits, let alone speak with their customers about this change in work practices.

Exception to the common case
The exception is the nicely improving Scrum or XP team.  These teams, depending on their heritage might simply be looking for the next most valuable thing to introduce to their team practices. Given the potentially massive pay-off by limiting WIP, you'd have a hard time trying to convince these teams to deal with much else before tackling WIP limits.

Have you read David Anderson's bookblog or heard him talk on the topic? I wonder what he has to say.

No comments:

Post a Comment