Kanban for software maintenance

Posted on March 15th, 2007 in Agile, Lean by siddharta || 1 Comment

David Anderson has an in depth explanation of the Kanban system that he has implemented for Corbis. This system implements various concepts from the Lean and Theory of Constraints schools. One of the interesting concepts is the feeding queue for each stage.

As an example, lets say that the stages in the process are Analysis, Development and Test. So a change request first goes to the Analysis state. Once that is completed, it is taken out of the Analysis state and moved to Development. Once development is complete, it moves to Test and so forth. Now each state has an input queue which determines how many requests can be handled by that state. So say analysis has a queue of 2, development of 5, and test of 3.

The system uses a pull-based system for moving change requests through the system. So when test completes a request, the request is taken out of its queue and placed into the release pool, leaving one space in the queue. At this point development finishes another CR to fill the gap, in the process creating a gap in their own queue, which in turn is filled up by Analysis. Once in a while (say every 2 weeks), a release is made with the fixes that are in the release pool.

There are a couple of interesting points to note. The first is that if the queue is full, the line stops on all previous states. So if the queue for Test is full, no development takes place, because there is no empty spot in the Test queue for the completed CR. And since development is not clearing its queue, Analysis stops as well. Yes, all the developers and analysts are kept idle. This might sound counter-intuitive, since it makes sense to utilize everyone who is available, but its actually a core principle in Theory of Constraints. The idea is to prevent a build up of inventory (in this case thats change requests that are in progress) in front of the state that is a bottleneck. If this is not done, then there will be more and more change requests that are in progress.

This also brings into focus that there is a problem at the Test state. By bringing the problem into focus, something can be done about it. For instance, if the problem is too few testers, then perhaps some developers could be moved into testing. If the problem is due to some special cause then that can be resolved. Either way, the problem is noticed and the problem is solved.

If the line was not stopped, then analysis and development would have continued but since test is not able to keep up, the backlog for test would keep increasing over time. But because everyone is busy, and things seem to be generally moving around, no one really notices that there is a bottleneck at the test state, and the problem is never fixed.

There are a few more interesting discussion points about this system that I’ll blog about in the next couple of days. In the meantime, read the article and don’t forget to check out the comments.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

One Response to “Kanban for software maintenance”

  1. Maintenance Procedure Says:

    This is one of the better blogs i’ve seen for maintenance procedure with lots of information and tips.It is full of information.I really appreciate for this blog.Thanks….

Leave a Reply