What is Kanban?

A Kanban system is a pull-based system that enables a team to optimize value by clearly seeing and adjusting their workflow. The Kanban system allows us to see the current state, the work in progress, and issues, such as bottlenecks in the flow. This enables continuous improvement.

Kanban (看板) is from the Japanese language and compromised of two kanji characters: kan (看) and ban (板) or signboard in English. It is based on lean theory, queueing theory, pull theory, and systems thinking.

Kanban optimizes a workflow towards three goals:

Customers receive value as they demand it
Utilize teams as efficiently as possible
Have a predictable delivery of value

What is Flow?

Flow is the movement of value. In Flow Theory, Little’s Law proves that it will take longer to complete items if too many items are in work simultaneously. The team uses cards to visualize work items. To optimize their cycle time, the team sets Work-in-Progress (WIP) limits for their work in progress. Over time, a team revises their WIP limits to respond to changes, such as new team members, new tools, or learning and improvement. WIP limit is not a constraint; it supports the team to work efficiently.

Kanban allows a team to understand their flow. It is a system that can enhance and improve flow from conception through delivery, support, and maintenance.

Who uses a Kanban system?

Kanban is not optimal for all types of teams. It works well with specialized groups, such as maintenance, operations, or support teams. In Scaled Agile (SAFe), teams use it at all levels from Portfolio to Large Solution and Essential. Multiple teams can share a Kanban board. Many scrum teams also use Kanban.

How do you know if a Kanban would be beneficial to your team?

Developed in 1999 by Dave Snowden, the Cynefin framework is a useful tool to determine if the Kanban system would benefit your team. The Cynefin framework has five environments. Depending on your environment, different work processes are helpful. In which environment does your team reside? Kanban works well for teams in the Clear and Complicated quadrants.

Clear: In this stable environment, routine solutions and best practices can solve the challenge. Maintenance teams often live in a clear state.
Complicated: In this environment, teams have a good process to “define and analyze” the challenge to devise and track a plan. It’s complicated, but at least we know what we don’t know. Many marketing teams work in a complicated state.
Complex: In this environment, you don’t know what you don’t know. Known practices and solutions won’t solve the challenge. Teams developing new software applications within nascent systems live in the Complex quadrant. The solution emerges as the team experiments and learns what works and doesn’t work. Kanban may not be an optimal process to use.
Chaotic: If chaos rules, it’s urgent to act to remove the danger immediately. Then, assess the cause and effect of the chaos to decide on the next steps, including moving into another quadrant (often Complex).
Disorder: Confused? Step back and gather information to figure out where the team resides.

Who uses Kanban and Scrum together?

On the surface, it seems that a timebox-based scrum and Kanban wouldn’t work well together. Many scrum teams, such as Marketing teams, who work in the “Complicated” state, find a Kanban to be extremely useful.

Scrum is based on two-week iterations (often two-week Sprints), while Kanban is a continuous flow system. A scrum team works within a Sprint timebox to complete and deliver a committed set of work. During a Sprint timebox, a team often uses a Sprint burndown chart to measure the remaining work to be done. In Kanban, replace timeboxes with a continuous flow of work.

A scrum team utilizing a Kanban system can manage this in different ways. Some teams create a ‘Sprint backlog’ column with WIP limits for their planned Sprint work. Other teams choose to have more work items in a generic backlog column with some work items prioritized and ready to be pulled. It’s a balancing exercise to have just enough in the backlog without creating the waste of refined backlog items that are never pulled. A scrum team no longer focuses on a timeboxed backlog; instead, they focus on the Kanban board. The team is not burning down to an empty queue at the end of the Sprint. The team is striving for a smooth flow.

How to build a Kanban board

With a new focus on a steady flow of work, a scrum team can begin to build their Kanban board. First, start with the most simplistic of Kanban boards with three columns: To Do, Doing, Done. Then, add other work states (columns) if it makes sense for your team. For example, a software development team may have the following columns: Backlog, Develop, Testing, Deploy, Done.

Cards populate the Kanban board. As the backlog is groomed just enough in the ‘To Do’ column, the team agrees to an estimate of effort and priority for each card. Prioritization ensures that the team only works on items that the customer desires. The team develops the minimal viable product (MVP) without overproducing. The estimate of effort on the cards helps the team to pull within WIP limits.

To gain efficiency, the team agrees only to pull work from one column to the next column if they have the capacity to work on it. To support this pull system, the team agrees on a Work-in-Progress (WIP) limit for each column. If a column has a WIP limit of 20 and is currently populated by cards that add up to 20 in the effort estimate, the team does not have the capacity to move another card to the column. It’s full, and there is no room to take on more work. Over time, the team learns and revises the WIP limits as they optimize their flow. Each time an issue like a bottleneck happens, the team learns. From this learning, they can decide to add resources, adjust how they estimate card points, or reset the WIP limit. This continual leveling of capacity smooths the workflow and reduces cycle time.

The team also agrees on work policies to ensure quality in every work state. For example, a team agrees to the definition of done for each column so they know when it can be pulled into the next column.Multiple teams can share a Kanban board. Sometimes, these teams add swim lanes (rows) to the columns. This can help visualize the larger body of work.

Kanban Flow Metrics

The goal of a Kanban system is to find opportunities to improve and improve the value provided to the customer. There are common performance measurements.

Cycle time – the amount of time from when a work item starts until it is completed. The goal is to optimize the flow to reduce the cycle time as much as possible. It demonstrates responsiveness.
Throughput – measures performance by the number of work items finished per unit of time. Lead time is measured from when a card enters the flow from the backlog to when it is completed.
Age – the amount of time between when a work item started and the current time. This applies only to items that are still in progress.
WIP – the number of work items started but not finished in each work state.

Many teams use a cumulative flow diagram to provide a view of cycle time, work in progress, and throughput. It will help teams spot waste (delays, rework, defects, etc.).

Scrum events for a Kanban team

A Scrum team running Kanban participates in scrum events. Although Kanban alone does not include daily scrum meetings or a set cadence of review sessions and retrospective ceremonies, it shares the intent of the formal cadenced scrum ceremonies, such as transparency, communication, collaboration, and continuous improvement. When a scrum team adopts a Kanban system, the scrum events support the existing Kanban practices with formalized events.

A Kanban system can be beneficial to your team. Sila can provide help you set up boards, focused coaching, and experienced agilists working daily with your teams on their boards.