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.

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.

Source Click Here.