David J.

Anderson and Associates - Kanban in Action

Pgina 1 de 1

KANBAN IN ACTION
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, weve released new versions of our IT
systems and business application software twice per month. However, sustaining doesnt 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 dont use
the Visual Studio IDE on a daily basis, the daytoday work is tracked on a white board using PostIT 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 workinprogress 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 selforganizing 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 selfexpedited 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 customervalued CR; Blue customervalued (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 workinprogress (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 timeboxed
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 miniproject. The
system has become largely selforganizing 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.

http://www.agilemanagement.net/index.php/blog/Kanban_in_Action/

19/01/2013