Kanban

This guide provides an overview of Kanban and its application to software development teams.

Kanban is a Japanese term meaning signboard or billboard. An industrial engineer named Taiichi Ohno is credited with having developed Kanban at Toyota Motor Corporation to improve manufacturing efficiency.

Intended for

Scrum masters, software engineers, hardware engineers, test engineers, and product owners.

Kanban for software development teams

While Kanban was initially created to help with manufacturing, software development teams share many of the same goals, including increasing their flow and throughput. By applying some of the guiding principles of Kanban listed below, teams can often enhance their efficiency and deliver value to their users faster.

Key Kanban principles

Pull model

Software development teams historically have had work pushed on them as stakeholders request more functionality, often with tight deadlines. A common side effect of this behavior is that quality suffers as the team is forced to take shortcuts necessary to deliver the functionality within the timeframe.

Kanban helps a team focus on maintaining an agreed-upon level of quality that must be met before the team can claim a piece of work as done. Stakeholders add requests to a backlog, and then the team “pulls” work into their workflow as capacity becomes available.

Visualize work

Understanding the status of a software development team in terms of both process and progress can be challenging. People can more easily understand the current state of work if it is shown using a visual representation rather than a large list of work items or a document describing the work being done.

Visualization of work is a key principle of Kanban. Kanban addresses this visualization using Kanban boards. Visualizing the work to be done as cards on a board, in different states, allows you to easily see the “big picture” of where the project currently stands, as well as identify potential bottlenecks that could affect productivity.

Limit work in progress

Teams that try to work on too many things often suffer from reduced productivity due to frequent and costly context-switching. The team is busy, but work doesn’t seem to be getting done, resulting in unacceptably high lead times. To address this, limiting the number of backlog items a team is working on at any given time helps increase focus while reducing context switching.

The maximum number of items a team decides to work on at any point in time is known as the work-in-progress (WIP) limit. A well-disciplined team will work to ensure they are not exceeding their WIP limit. Should this occur, the team will investigate the reason and work to solve the root cause of the issue.

Continuous improvement

For software development teams to continuously improve, they need ways to measure their team’s effectiveness and throughput. Kanban, through the use of the Kanban board, provides a dynamic view of the state of work in a workflow. This allows the team to experiment with different processes and evaluate their impact workflow more easily. Teams that practice Kanban often utilize measurements such as lead times and cycle times and generally embrace the benefits offered for continuous improvement.

Kanban boards

A Kanban board is just one of many tools you can use to implement Kanban practices in a team. It can be a physical board or a software application that shows cards arranged into columns. Typical column names include "To-do", "Doing", and "Done", but teams can customize this to suit the states in their workflow. For example, "New", "Development", "Testing", "UAT", and "Done".

Software-based Kanban boards can display cards corresponding to product backlog items and include links to e.g. tasks and test cases. The following screenshot shows an example of a software-based Kanban board.

On a Kanban board, a WIP limit is applied to all “in-progress” columns. The first and last columns on a Kanban board do not have WIP limits. In Figure 3, assuming the WIP limit is 5, the testing column is exceeding the limit as illustrated by the bold column title and the change in color to red. This indicates that there may be a bottleneck in testing that is impeding the team’s flow. Once identified, the team can determine an appropriate course of action to remove the bottleneck.

Cumulative flow diagrams

A common addition to software-based Kanban boards is a chart called a cumulative flow diagram (CFD). This chart illustrates the number of items in each state over time, typically multiple months. The horizontal axis shows the timeline, while the vertical axis shows the number of product backlog items. Colors are used to indicate the state (or column) the cards are currently in.

This chart is particularly useful for identifying trends over time, including bottlenecks and other disruptions to a team’s velocity. An example of a good CFD would show a consistent upward trend while the team is working on the project. The various “stripes” across the top of the chart area should be roughly parallel if the team is working within their WIP limits.

If one or more of the stripes show a bulge, this is usually a clear indicator of a bottleneck or impediment in the team’s flow. In the CFD shown below, you can see that the completed work (green) is flat, while the previous state, Testing, is growing, which indicates a probable bottleneck.

Agile, Scrum, and Kanban

While broadly fitting under the umbrella of Agile, both Scrum and Kanban are quite different. A few of the most notable differentiators include:

• Scrum focuses on fixed-length sprints, where Kanban is more of a continuous flow model.
• Scrum has defined roles, where Kanban does not define any specific roles for the team.
• Scrum uses velocity as a key metric, whereas Kanban champions the use of cycle time.

In highlighting the differences in the previous paragraph, it is also common for teams to adopt aspects of both Scrum and Kanban to work most effectively. Remember, regardless of which characteristics you choose, you can always review and adapt until you get the best fit for your team. Start simple and don’t lose sight of the most important thing – delivering value regularly to your users!