Become Agile, Go Kanban

person Bijeshfolder_openOtheraccess_time May 14, 2010

My organization is moving onto experiment with Lean development.  Lean comes from the manufacturing sector but fits surprisingly well into software development. After all, Lean is not specific process but a set of principles. Some of the main principles of Lean include removing waste, delaying decisions, delivering faster, building in integrity – all of them aiming to get products/services out to the customer speedily. What’s more! Agile practices like Scrum help achieve some of these principles. For e.g. the backlog in Scrum enables delaying decisions like what will go into the final version of the product, etc. Read this excellent article that maps Scrum practices to the Lean principles and how a team can use Scrum to go lean!

Sustaining and Kanban

While Scrum works very well for teams involved in a typical development cycle, it is not flexible enough to adapt to a maintenance oriented team. We have a dedicated team that works on product bugs reported by customers. They reproduce, fix and release fixes regularly. Any maintenance/support team has to work within the complexities of changing issue severity, customer impact and unpredictable resolution times. As a result, the concept of product (or in this case issue) backlog and sprints cannot be used in a maintenance/support team.

This is where Kanban comes into the picture. Kanban can be applied to a waterfall model as seen in sustaining teams. Read David Anderson’s paper – A Kanban System for Sustaining Engineering.

In our sustaining team, the main focus is on three kanban concepts – Limiting WIP, Self Directing and Pull Production. How do they help?

Limiting WIP

At any given time, the sustaining team maintains about 3 or 4 versions of a product and about 10 different components within a version. Pre-Kanban, every resource on the team worked on a large number of issues simultaneously. The context switching was a huge overhead as every switch potentially required starting up a particular version of the product, installing reproducible cases and sometimes switching between product components. Now, with the limited WIP, the team is limited as a whole to have X issues in progress and as a result every individual is limited to a much lesser load. This not only saves context switch times but also allows the individual to focus on one (or two) issue at a time and push them out of the queue.

Self Directing

The Kanban master merely prioritizes the issues in the To Do column of the Kanban board. Except for production-impact issues, all other issues are self assigned by the individuals. This ensures that the individual picks up tasks in accordance to available capacity and thus don’t get overloaded. In addition, it allows individuals the opportunity to pick up issues in areas that they would like to work on – translating into motivation and pride.

Pull Production

The issues are never pushed from the upstream states. They are always pulled by the downstream states. This means that if there is a bottleneck (a downstream state being full), the team will know and they can work together on the bottleneck and get it out to the next state.

We started out with a physical kanban board using coloured Post-It Notes. The colour of the note signified the severity/priority of issues. The board was the talk of the office and drew a lot of interest from other teams. Our throughput was sometimes too high and meant regularly going up to the board to shift the notes. And the post-its kept falling off the board :-)

We have since switched to an online version hosted by It’s accessible and available 24/7 whether we are in office or working from home. It’s not as much fun as the physical board but it works very well.

We have been using Kanban for about 2 months now. The board has changed quite a bit from its original state – one of the good things about kanban is that it is meant to be continuously improving/changing. We are in a fairly static state now but we do expect to optimise the board further.

In the 2 months, we have managed to cut down our issue backlog by about 15% inspite of seeing 2 weeks which showed a steep rise in new bug reports. Kanban sure has worked wonders for our team and we are hoping to keep it that way.

Update (11th July): The team went on to break a record of sorts. After compensating for the inflow, our backlog is now down by almost 50% now. Kanban does work.

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>