In this article I will be talking about my favorite way to manage flow of work through a software team, Kanban.

Kanban is a great way to gain team agility without requiring changes to existing processes. Kanban allows these processes to be improved over time with minimal impact to how a team works, while giving full visibility on the process and bottlenecks within the delivery system. 25% of respondents on the version one state of agile survey said they were using Kanban . In a nutshell, Kanban…

• Helps visualize the development process and bottlenecks within the delivery system
• Enables agility within existing development processes
• Improves the speed of delivery of software to the business users requesting it
• Enables a continuous improvement culture within a team
• Uses an SLA based scheduling approach
• Uses frequent delivery of usable software on an agreed schedule with business users
• Improves team morale

What is Kanban?

Kanban is a technique for managing software development in an efficient way. It is not a development process in itself and can be used to improve the performance existing development processes (e.g. Scrum). As it doesn't mandate drastic changes in the development process and it can be used as a change agent that gradually improves delivery performance over time with minimal impact to staff and processes.

At its core it is a visual system designed to help:

• Visualize the development process as a pipeline of stages
• Visualize the current state of items being produced within the process.
• Visualize current resource assignments for items within the process.
• Visualize blockages to items being produced within the process.
• Visualize Work in Progress Limits within the system (see below).
• Visualize lead times for classes of work items within the process.
• Maximize the throughput of bottlenecks within the system in order to increase the flow of items through the system.

In manufacturing a Kanban card is a visual signal that more inventory needs to be produced and is used to control waste in the system. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production.

In Kanban for software development we use a physical board and system cards to display work items within the development process. Typically the board is divided into the various columns representing the phases of the development process. As items are developed the cards are pulled through the different columns in the board by development resources that become free. At a glance, the Kanban board gives a clear picture of where things are within a current release. Each card on the board gives a clear status for items being developed.

Example Kanban Board

Below is a sample similar to board formats that I've used in the past:

• Each column is a step in the value chain. The ready for dev column is a set of groomed items in priority order, most important at the top.
• The lead time for delivery is written clearly on the board beside the ready for dev column.
• Each column has a work in progress limit which represents the capacity of the resources working in that column, or the limits of the bottleneck of these resources (see below for details)
• The definition of ready/done for each column is written in a section at the bottom of the board. This makes it easy for team resources to check whether they have done all important tasks before the item can move.
• Different coloured cards are used for different types of item. e.g. Red for bugs, yellow for development tasks, making classes of item clearly visible.
• Some columns are Queue columns. I usually put a queue in front of system test column up to a limit. Testing is usually a bottleneck in the system due to the developer/tester ratio. By adding a queue developers can start on the next development task while testers are completing its current batch. However, once the ready for test queue reaches its WIP limit, developers may switch to Kaizen tasks.
• Paper tabs are used to denote who is working on a task (blue) and which tasks are blocked (red). Using tabs in this way is a great way to impose a physical limit that a certain name can only be assigned to a single task at a time. Red tabs are used to visualize items that are blocked and can be initialled to denote who raised the blocked issue.
• An expedite queue is included at the top and is for emergency items the team may be working on. The policy is usually that an expedite item freezes all other work on the board until it is complete.

Electronic vs Physical Boards

Some of the electronic work tracking tools available today, such as Atlassian Jira or Visual Studio Team Services are really feature rich and the Kanban boards they provide do a great job. Benefits include automated reporting of team metrics (e.g. for calculating lead times) and integration with other systems such as email. However, there are also limitations. For example, Kanban works best when work is always visible to the team. With electronic boards, this is not always the case. Not all teams have large screen displays in every meeting room and having to pull up the board on laptops or projectors before progress can be discussed can be a real time sink. Also, some of these electronic tools can be overcomplicated for smaller teams.

On the other hand, the benefits of a physical board are:

• Work is visible always to everyone in the office.
• Mobile whiteboards can be easily carted around the office and in to meetings.
• The board imposes physical limits on the number of cards that can be added to the columns. This acts as a physical WIP limit for the team.

The downsides of a physical board are:

• The board is only visible locally to the team. This can make it hard to share information with a wider audience, say, international teams.
• No automated reporting of lead times is available and it must be done manually.

One strategy when considering a physical board is to run a backup electronic board for calculating statistics and reports, which the scrum master keeps in sync with the physical board.

Anatomy of a Kanban Card

For Kanban cards a standard index card can be used. Printing the index cards is a great way to make them legible and tidy. The card should make visible any pertinent process related info that helps discussing and helps it flow through the process.

Here's a sample similar to a card layout I've used before:

• The number records the electronic boards number if one is being used as a backup.
• To generate metrics, key dates are recorded in the top right of the card. It's important to record at a minimum the card creation date, when the team started working on it, and when they completed it.
• A clear description of the item appears in the centre of the card.
• A definition of done is included in the bottom left of the card. This gives a quick visual indicator to the team of the "done-ness" of the item and when it can pulled downstream. If certain activities are not required they can be crossed out. Having a definition of done on the card is an alternative to adding a done column for each phase on the board and is a good space saving technique.
• Notes are maintained on the bottom right. For example, the team might note the due date for the item as requested by the stakeholder, or if collaboration with an external team is required before the item is "done done"

This card layout is an example only. Kanban encourages that a team tailors the visual system (board and cards) to suit the process of the team. This is an evolutionary process, where the team tries something and keeps it if it improves the process, and discards it if it doesn’t. Changes are evaluated in the regularly held retrospective meetings.

WIP Limits and Flow

Batch size (or the number of items in a release) has a direct impact on lead time and quality. What this means is that the more items a team is working on at the same time, the longer it will take for items to make their way through the development process and be delivered to the business. At the same time the rate of defects will increase. This is due to the following factors:

• The time for each type of activity (analysis, development, testing) that needs to be completed within the release increases, and this impacts the lead time for items in that release.
• The potential for complex dependencies between items increases if the scope of a release increases.
• An increase in complexity requires an increase in the amount of management and planning required for the release.
• Defect rates increase as the scope increases and the time between analysis, development and testing increases. This can simply be due to the fact that there is a greater scope to discuss, implement, test and more potential for things to get lost in the mix.
• The time required to sign off a release increases as there is more functionality for business users to consider.
• The risk associated with a release increases as more code has changed in a large release, also meaning that it’s harder to find issues when something goes wrong.

So keeping a small number of items per release and releasing more regularly promotes team agility by reducing lead time, reducing management overhead and reducing defect rates.

Kanban maximizes flow through the development pipeline by keeping the number of items in a release at an optimum level, known as the Work In Progress limit (WIP). Small batch sizes are achieved by setting work in process limits for each phase of development within the development process. These WIP limits are usually set based on the capacity of resources within that development phase.

This WIP limit ensures that bottlenecks within the system are exploited at 100% capacity. For example a development team may have 4 developers available. The WIP limit for the development phase of the pipeline may be a maximum of 4 items being worked on at any time (or 2 if pair programming is being used). Typically WIP limits are displayed on the Kanban board at the top of each column.

There is a great Yow conference video by Don Reinertsen on the effect of batch size on throughput here:

https://yow.eventer.com/yow-2012-1012/the-practical-science-of-batch-size-by-don-reinertsen-1269

Pull System & Kaizen Culture

Kanban implements a pull system, which means that cards pulled from left to right on a board as resources become available. e.g. Developers will pull tasks from the "Ready For Dev" column when they have finished development on their current item. Testers will pull development tasks into the System Test column when they are out of items to test and there are development items ready to test.

Since it is only the bottlenecks in the development process that are working at 100%, the pull system can create slack within the development process. For example, a developer cannot pull a card unless their current card has been pulled into system test by the testers. This means the developer must wait before starting new work.

With Kanban this slack is considered to be a good thing and gives time to develop a self-improvement culture within the team, referred to as a "Kaizen" culture. Waiting resources focus on "Kaizen" tasks that are aimed at improving the development process or team resources in some way. This might be optimizing the builds, training, blogging etc, etc. Developing the Kaizen culture is the core of how Kanban enables team agility.

In terms of managing the Kaizen tasks, by their nature they should be tasked that can paused easily if the bottleneck has cleared in the process. I've seen Kaizen work best when the team maintains a much simpler "To Do, Doing, Done" style Kaizen board separate to the main delivery board.

More on Kaizen can be found here: http://en.wikipedia.org/wiki/Kaizen

Outcomes and challenges using Kanban

Using Kanban I have seen the following positive outcomes for a team:

• Everyone on the team gets a clear understanding of the development process and the state of items in the team as all work is visible.
• Delivery becomes more efficient as Kaizen tasks are being completed to improve the development process (e.g. automating manual tasks)
• Team members work at a sustainable rate of development while delivering continuously.
• Meetings (scrums and retrospectives) become very focused on delivery and take the minimal amount of time necessary. Scrums become focused on flow of work and discussions are about coordination and blocked issues on the board.
• Team morale increases due to the team working effectively together.

Kanban works well if items being requested are of a consistent size. If they are, then meeting SLA's for upstream requesters is easy. Care needs to be taken at the input queue (our Sandbox) to slice things up in a consistent way (e.g. a small number of acceptance criteria per story). This may not always be possible though, and Kanban requires that any variability in size is managed accordingly.

Kanban also works on an SLA basis for delivery instead of upfront planning. The rationale for this is that if items being delivered are of a fairly consistent size, and a small batch size is used per release, then over time the delivery frequency of items averages out.

Team Metrics

The key to successfully using Kanban to improve flow is to monitor team throughput metrics. You can go as complex as you like with this, but at a minimum I like to track the following items:

• Number of Items in Flight
• Number of Items "Done Done"
• Average Lead Time (From requested to done done) +/- Std Deviation
• Average Dev Time (From dev start to done done) +/- Std Deviation
• Max Lead Time
• Max Dev Time

A simple monthly report on these figures might look like the following, and is very simple to create in Excel. This kind of report can be used in retrospective and for high level planning with stakeholders.

Resources

The "Kanban" book by David J. Anderson is a really great resource on the topic, highly recommended if you are interested in using Kanban. You can get a copy on Amazon.com