What is kanban?

"Kanban" means "billboard/placard” in Japanese. Kanban is also one of the most popular frameworks used by agile software development teams. Kanban supports agile methods through the continuous delivery of high-value features.

Cards on a kanban board that represent work items are organized in vertical columns that represent status. New features are pulled from the backlog and added to in-progress work as team capacity allows.

Practical example of a kanban board created in Aha! Develop

Kanban is significant because it is a pull system. Work is often pushed onto development teams based on estimates of team capacity but software development is not exactly a predictable endeavor. Kanban establishes work-in-progress (WiP) limits and measures throughput.

Teams that practice kanban are typically self-directing. Resources are only pulled in as they are needed or requested — teammates can claim work based on actual bandwidth. This is a huge contrast to being assigned future work by someone else using capacity estimates.

This guide provides an overview of the origins of kanban, the principles of the method, and the processes for implementation. Feel free to skip ahead to the section that you need:

The origins of kanban

Taiichi Ohno introduced kanban at Toyota in the late 1940s. He was an industrial engineer and eventual executive at the company. Today he is considered the “father” of the Toyota Production System, which inspired lean manufacturing in the United States.

At the time, Toyota was struggling to compete with the American car market. So Toyota looked at how other supply chains handled fulfillment by matching inventory levels with consumption patterns. Specifically, they studied supermarkets. Stores stocked products based on what they could sell in a specific time. Customers bought what they needed since they knew they could buy more later. This research led Toyota to see consumer demand as part of the manufacturing process — a required input precedent to production.

Most car manufacturers still followed Henry Ford’s method, producing a great quantity of parts (doors, engines, etc.) that were piled beside the assembly line to be used as needed. But this approach required huge amounts of upfront capital, which was challenging in post-World War II Japan. Ohno aimed to eliminate overproduction by introducing new inventory only when absolutely necessary. Factories were reorganized so that parts production and assembly happened at the same rate, with assembly workers taking parts only as needed. They called it the “just in time” (JiT) method — but more on that later.

Remember that supermarket research? Ohno realized that there needed to be some exchange that triggered restocking the shelves. So he introduced paper cards called kanban. Once a material was used, a kanban card would be sent back to parts production indicating to the team exactly what was used and how many more were needed to restock.

Over time the kanban method evolved to support many different supply chains — basically anything that required visualization of a large volume of in-progress work. But the next evolution of kanban occurred in the early 2000s when the method was adopted as a project management tool by IT and software development teams.

Many assumed lean manufacturing principles would not extend to knowledge work. But a 2004 case study of IT teams at Microsoft proved the efficacy of these concepts in managing change requests and backlogs. One of the authors of that case study, former Microsoft engineer David J. Anderson, was credited as among the first to apply kanban to software development. He went on to write many books about agile and lean methodologies. (And he even opened a kanban “university” as well as his own eponymous school of management.)

What are the principles and practices of kanban?

Kanban is a method — not a methodology. Unlike other agile frameworks, there is not a list of rules, roles, and ceremonies that must be followed to “do kanban right.” But there are some general principles and practices.

Two principles guide kanban in software development. First, visualize your work. A lot of development work is “invisible” until it is completed. So it is useful to have a high-level view of work items so you can identify delays or blockers and keep everything on track.

Second, limit WiP. It is hard to do 100 things at once. You might get them all done eventually but it will take a long time and quality will undoubtedly suffer as you stop and start, with context switching between each item. You can complete projects faster if you prioritize what is most important, limit how much work each person has, and focus on delivering frequently.

Software development is full of uncertainty and complexity. JiT puts an emphasis on delivering the simplest solution to a known issue (not anticipating future unknown needs) in small releases to avoid waste. It might not be a principle of kanban per se, but it is definitely part of the conversation.

Now, onto the practices of kanban. You will find various versions of the list below:

  1. Visualize work

  2. Limit WiP

  3. Manage flow/lead time

  4. Make policies explicit (it is hard to improve what you do not know)

  5. Implement feedback loops

  6. Improve by team consensus and use models to predict impact of change

Kanban definitions

Although kanban does not have the plethora of terminology associated with many agile workflows, there are a few that those new to the method might not be familiar with.

Backlog

Consolidated list of work items (e.g. user stories, bug fixes) that need to be completed but have not yet been prioritized. Typically the first column on your board is the backlog.

Boards

A physical or virtual board that is organized into columns — each column represents a status. Common statuses include: Up Next, In Progress, and Done.

Blocked

Indicates a problem with a work item that prohibits it from moving forward.

Cards

An individual work item, such as a user story or feature.

Cumulative flow diagram

A visual chart that shows cycle time, work in progress, and throughput during a given time period in colored bands.

Cycle time

The time it takes for a card to move from prioritization to completion.

Lead time

The time it takes for a card to be prioritized from when it was added to the backlog.

Scrumban

Hybrid methodology originally meant to facilitate teams moving from scrum to kanban.

Swimlanes

Horizontal lines that split status columns into sections. Swimlanes can be used to represent teammates or organize tasks by type/priority.

Throughput

The number of cards that move through statuses during a given time period.

Work-in-progress (WiP) limit

How many cards can be worked on at any time, in any status/lane.

Kanban vs. scrum

It is worth taking a moment to compare kanban to one of the other most popular agile frameworks: scrum. Kanban pulls, scrum pushes. Kanban is flexible, scrum has a defined framework. Kanban limits WiP to balance work against actual capacity, scrum relies on estimation in story points. The table below gives you a high-level comparison of the two.


Kanban

Scrum

Roles

There are no defined roles but some teams have service delivery and service request managers.

Product owner and scrum leader

Release cadence

Continuous

Defined intervals called sprints (e.g. two weeks)

Delivery

Continuous

At the end of each sprint, as approved by the product owner

Change

Change can happen at any time.

Changes should not be made to the sprint forecast during the sprint.

Meetings

There are no defined meetings but meetings are broken out by team-level (e.g. daily standups) and service-level (e.g. delivery and risk review).

There are four mandatory meetings: sprint planning, daily scrum, sprint review, and sprint retrospective.

Performance metrics

Lead time and cycle time

Velocity and planned capacity

What are the benefits of kanban?

Organizations often see radical increases in productivity as a result of adopting the kanban method. Kanban increases transparency and communication since work and status is visualized in one place. With a glance, you can evaluate who has the most work and who has the least.

But in the minimalist spirit of the method, here is a simple list of benefits:

  • Flexibility — no defined framework makes it adaptable to different organizations.

  • Delivery — continuous delivery means faster value creation with more opportunities to incorporate feedback into future iterations.

  • Productivity — priorities are constantly reassess based on the most recent information.

  • Waste — less questioning about what to work on next, less administrative overhead.

  • Morale — teammates have more room to focus on work and process improvement is collaborative.

How to implement a kanban system?

A kanban system is a defined workflow management method. It is about defining, managing, and improving the delivery of services. You are able to visualize your work, reduce waste, and better respond to change.

The practices referenced earlier provide a blueprint for effectively implementing kanban on your own team. Here is a brief summary of the steps to take:

1. Visualize work

Map out the processes that you currently use to deliver new functionality to the columns that will be on your board. You will also want to decide how you will actually manage your board. Are you happy with the tactile nature of a physical sticky note board? Or do you want a more dynamic virtual kanban board?

2. Set your WiP limits

Decide on a limit for the number of cards that can exist at any time in any column.

3. Make policies explicit

Capture exactly how the backlog will be managed and define how you will handle defects and bug fixes.

4. Measure and manage flow

Delivering continuously means you need to insert criteria for evaluating and understanding your performance. Most teams use cycle time and throughput to do this.

5. Gather feedback and optimize

Every teammate should feel empowered to give feedback on how processes can be improved at every phase of work. Approach each optimization like a scientific experiment — formulate a hypothesis, then monitor the outcome of any changes you make.

How can kanban be used at scale?

Kanban at scale takes a multi-layered approach that treats the organization as a complete system. The Scaled Agile Framework® is a good example of this. In SAFe®, kanban is used to visualize workflows, establish work-in-process limits, measure throughput, and continuously improve processes — at every level. These levels include:

Portfolio

Kanban is used at the portfolio level to manage the flow of epics. These are large initiatives across the organization that span teams and multiple releases. Portfolio kanban encourages transparency in decision-making processes and provides work-in-process limits across teams.

Solution

Kanban is used at the solution level to manage a team's capabilities. For example, establishing a continuous delivery pipeline could be its own unique kanban.

Program

Kanban is used at the program level to manage features for an Agile Release Train (ART) — which includes all of the work needed to build, test, deploy, and release new software or a customer experience.

Team

Kanban is used at the team level to manage an individual team's workflows. For example, product managers apply kanban when working from discrete planning boards. Agile engineering teams apply kanban when managing user stories and the engineering backlog. Some organizations choose to visualize all teams on one board with a lane per team to provide better transparency and alignment.

The power of kanban is more than just visualizing workflow. It pushes the team to set clear priorities and work together better. This is why both Aha! Roadmaps and Aha! Develop support customizable kanban boards — allowing product and engineering teams to work the way they want.

Streamline your agile development process with Aha! Develop — try it for free for 30 days.

Sign up today!
Start your 30 day trial. No credit card required.
© 2021 Aha! Labs Inc.All rights reserved