Kanban in action

Kanban is a Japanese term common in the lean literature meaning a signaling device: downstream activities signal to an upstream activity when they have capacity to do more work, enabling value to be pulled through to a customer in continuous flow. In software, it starts with a ranked backlog of stories/features to be done, just like in agile. But instead of fixed iterations or sprints, the team pulls items the highest priority items from the backlog as soon as it has capacity. Software may still be released on a regular cadence, and the release includes whatever backlog items have been completed on the release date.

This blog post is a great primer describing how kanban was applied at Corbis.

I have always thought that the schedule pressure of short iterations can have a positive motivating effect on team member and keep them focused on the goal, but I realize now that it can also have negative consequences, invoking feat and causing developers to feel pressured to make short cuts and bury quality problems under the rug in order to give the appearance of completing tasks on time. David Anderson addresses this issue eloquently in this post on the kanbandev discussion group. In a nutshell, David describes how the objective in a kanban system is to reduce cycle time while maintaining quality. With those measurements in place, the team is motivated to continually improve but the system is tolerant of missteps and underestimation on individual features. Done properly, a kanban system should eliminate the potential negative motivations that can be caused by iterations.