Kanban in Action

Posted on March 08, 2007 by admin

Earlier when I described my approach to managing and leading software engineering at Corbis, I mentioned that I was introducing a kanban system for our sustaining engineering activity. Since we introduced it, we've released new versions of our IT systems and business application software twice per month. However, sustaining doesn't run on a traditional agile two week iteration (or sprint) type system. It uses a kanban system to pipeline change requests (CRs). When a CR is complete it sits in the Release Ready state until a scheduled release happens on every second Wednesday.

Though we track all CRs in Team Foundation Server using the TeamLook client for Outlook to provide access for those who don't use the Visual Studio IDE on a daily basis, the day-to-day work is tracked on a white board using Post-IT notes as kanban cards.

Our sustaining process is driven from a floating pool of regular software engineering resources, there is no dedicated sustaining or maintenance team. By setting a kanban limit we can guarantee to the Governance Board that we are meeting our commitment to dedicate a certain percentage of our resources to sustaining activity, without dedicating specific heads.

Each morning the team meets for a standup around the kanban white board to discuss the work-in-progress and how to keep it moving. Darren Davis, a manager on my staff, can be seen leading the meeting, working through each card and discussing it with the assembled (virtual) team. The cards on the board contain the title of the CR, the ID number from Team Foundation Server (TFS), and above each card is written the name of the currently assigned member of staff. Team members are responsible for updating the board and moving kanban cards as they progress a CR through the system. Darren uses the daily standup to insure that the electronic data in TFS is synchronized with the physical board. The kanban system is essentially self-organizing but with a management validation point daily.

The key to the board is worthy of description. A red star indicates that the item is severely aged and exceeds the 28 day service level agreement (SLA) for processing through the system. This allows the "late" item to be self-expedited without direct management intervention. Blocked CRs have pink sticky notes attached to indicated that there is an open issue in Team Foundation Server. These pink cards also contain the description of the issue and the ID number from TFS. There are some other types of notes on the board for bugs and maintenance CRs. Here is the key: Yellow - customer-valued CR; Blue - customer-valued (and requested) bug (fix); Green - IT maintenance item e.g. SQL 2005 upgrade; Orange - additional (or extra) bug; pink - issue.

The kanban limit for the system is 20 cards, divided in to different stages in the process - systems analysis, development, test, build/merge, deployment. In addition, we allow for 3 extra bugs to be anywhere in the system. This separate kanban limit of 3 bugs allows us to burn down the bug backlog using slack resources. When these resources are not available, we will remove or reduce the limit of 3 "extra" bugs. There is also an additional kanban limit of 2 maintenance items. This allows us to fix a small percentage of IT resources to do vital systems maintenance and upgrades such as API version upgrades, and platform upgrades like .Net2.0 or SQL Server 2005.

The kanban system allows us to deliver on 3 elements of my recipe for success: reduce work-in-progress (in fact it limits it completely); balance capacity against demand (as new CRs can only be introduced when a kanban card frees up after a release); and prioritize. We hold a business prioritization meeting once per week with vice presidents from around the company. They get to pick new CRs from the backlog to allocate against free kanban cards. This forces them to think about the one, two, or three most important things for them to get done now. It forces prioritization.

The kanban system also frees us from the constraints of time-boxed iterations. Even though we are making a release every two weeks, items in the system can take up to 60 days to move through depending on their size and complexity. Items that would be too big for a single two week iteration can still be fed in to the system and will work through and be released without any special management attention.

And finally, the kanban system has freed us from the management overhead of running each iteration like a mini-project. The system has become largely self-organizing and little management attention is required unless exceptional circumstances emerge requiring an expedite request or a date change to a scheduled release due to environment or system maintenance issues.