Introducing Kanban at Xclaim

We’ve rolled out Kanban at my company Xclaim Software. Prior to this we were following a more-or-less XP process evolved and tweaked over some two years.

Xclaim Kanban 1.0

Even though our team has been doing the Agile thing with good results, there are times that the process seems a little opaque and wasteful. I’ve noticed that it’s hard to surface where we’re encountering bottlenecks or impediments. Planning and maintaining a large inventory of backlog creates waste; planning can take several hours for large batches of new stories and, while I think there’s good value in preparing a as-full-as-possible backlog at the beginning of a project, I see very little value in maintaining a backlog over three months at a maximum. There’s simply too much risk of redundancy and re-work in a large backlog.

For a while now I’ve seen iterations as an arbitrary nuisance. We all know velocity is a yardstick measure that’s imprecise and best used for rough planning. We can also take points delievered over any two points of time and compare this number to previous durations to develop a trendline. Over a longer history we can use these numbers as a measure of throughput and improvement. Why then do we need to make them reset every Wednesday? If we’re using similarly-sized items — which we are — it seems that feature cycle time (time from ‘activation’ to ‘in production’) is equally useful and much more understandable by both customer and developer.

A big source of waste, waste due to over-processing, is the planning, retrospective, and customer demo ceremonies. It’s easy to burn a half-day or more in these meetings and the fact of the matter is that a lot of these things can just be JIT’d on an as needed basis with the right people getting us much closer to the lean concept of pull.

Is it too much of a stretch to say project determines process? Every project we work on and environment we work in will come with requirements that drive a customized process. Of course we can’t get there from day one. We need to setup a good baseline with the practices we know have broad applicability, acceptance, and tolerance: TDD, rolling wave planning, etc. Good Agile teams, however, continually adjust their process to fit their product and the needs of their customers. In a sense, we’re designing our process as we go and this is something I see Kanban encouraging.

There’s a few things to say about this Kanban thing we’ve got going on, and I’d like to tackle this as a mini-series to make the posts digestible. I’ll continue with five installments to start:

1. Why bother? Pull, flow, throughput and constraints.
2. Anatomy: queues, buffers, work-in-process, standard work and order points.
3. Developing and introducing a Kanban in your team.
4. A tour of our initial Kanban pipeline.
5. Handling rework and the zero defect mindset.
6. TBD

If you’re interested in Kanban, I highly recommend subscribing to the Yahoo! Group. You may also want to check out Corey Ladas’ blog; he writes about the practice with some regularity, sharing valuable insight and experience.

This entry was posted in Agile, kanban, lean. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to Introducing Kanban at Xclaim

  1. Alan Stevens says:

    Dave, it is great that you have so much influence over your process and customer. This is necessary for the degree of waste reduction you are attempting. Unfortunately we do not all have such influence and the ceremony of demo and retrospective is still the most productive approach. You are on the leading edge and it is fascinating to observe from back where I stand.


  2. Dave Laribee says:

    thinking on this a bit more…

    at the strategic level it is also good to practice gemba, going to the place where value is added. practices like the VP of dev or CTO sitting in the team room and _observing_ are also quite good.

    i also have this idea that hansei or self-reflection items could be logged in a kanban of its own and triggered as an order point. JIT the organizaitonal reviews. I helped one of our clients (an insurance company) do this for departmental meetings which can be quite wasteful.

  3. Dave Laribee says:

    (Note: cross posted on the Y! list, interested people should subscribe.)

    I agree completely.

    On the tactical level we stop the line all the time. Various people will address the team room during the course of the day to say “this is screwed up, let’s change [standard work] here” or we’ll surface ideas for continuous improvement in the stand-up. These little episodes often introduce or vet ideas that get implemented later on. Of course, sometime these items are around the domain of our product and help spread tacit knowledge. Those two items (continuous improvement and increasing knowledge) are often what retrospectives deal with. Redundant!

  4. [Let’s try this again. Please delete the previous one]

    I’ve posted my own thoughts on this thread at my blog . As trackback seems to be an antiquated and broken concept, I’ve simply provided the URL.

    Dave, Thanks for posting this and Derik and Steven, thanks for the conversation. It really helped me distill an idea that’s been bugging me for years.

    Cheers, David

  5. Dave Laribee says:

    @Derik & @Steven

    Andon (visual management, usually signaling a potential line stop) is where most tactical retrospectives happen. We do this anyway. It’s kind of the situation where someone will say "hey guys, let’s do it this way."

    Other than that, there’s really very little need to have a retrospective once a week or synchronized with an iteration. We are toying with the idea of creating a seperate queue for retrospective items that’s triggered when we get an acceptable batch of items.

    The demo can can be wasteful, yes. We get about 25 people in a weekly demo regularly. Sometimes we have only two things to show. In the mini-series I’ll get into how we’ve modeled our acceptance queue (demo/beta), but for now it’s sufficient to say that we trigger a meeting when we get three or more Kanban in the demo queue. I’ve also started to think that a customer team might be a more efficient approach that yields most of the intended benefit. More on that later…

  6. Along the same lines as Derik’s comment, I can totally see how the retrospective can be viewed as wasteful in the context of Kanban – where every developer has the ability to Stop The Line the minute they detect a problem.

    I suppose the challenge there is getting folks to adopt and accept a stop the line culture – often I find we become complacent and accept things as “good enough” when really we need to be addressing issues the instant we feel the pain.

    Ok… rambling now… time to get back on track.

    What changes did you make that allowed you to get the benefits of the demo worked into your Kanban-based development environment, thus allowing you to identify the explicit “demo stage” as wasteful?

  7. I find it interesting that you find the retrospect and customer demo’s wasteful. If you are able to pull in the key customers on a ad-need basis i guess I can see how it may be a bit wasteful.

    However, not all teams have that luxury. Also, I have found that developers really learn alot about the software they just produced during the demos. This allows for an open forum to have open conversation/debate about the direction of the product.

    My 2Cents

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>