Agile Glossary

Kanban

What is Kanban?

The Kanban Method is a means to design, manage, and improve flow systems for knowledge work. The method also allows organizations to start with their existing workflow and drive evolutionary change. They can do this by visualizing their flow of work, limiting work in progress (WIP), and stopping starting and starting finishing.

The Kanban Method gets its name from the use of kanban – visual signaling mechanisms to control work in progress for intangible work products.


Also Known As

A general term for systems using the Kanban Method is flow – reflecting that work flows continuously through the system instead of being organized into distinct timeboxes.


When Applicable

Kanban can be used in any knowledge work setting and is particularly applicable in situations where work arrives in an unpredictable fashion and/or when you want to deploy work as soon as it is ready, rather than waiting for other work items.


Values

Teams applying Kanban to improve the services they deliver embrace the following values:

Transparency – sharing information openly using clear and straightforward language improves the flow of business value.

Balance – different aspects, viewpoints, and capabilities must be balanced in order to achieve effectiveness.

Collaboration – Kanban was created to improve the way people work together.

Customer Focus – Kanban systems aim to optimize the flow of value to customers that are external to the system but may be internal or external to the organization in which the system exists.

Flow – Work is a continuous or episodic flow of value.

Leadership – Leadership (the ability to inspire others to act via example, words, and reflection) is needed at all levels in order to realize continuous improvement and deliver value.

Understanding – Individual and organizational self-knowledge of the starting point is necessary to move forward and improve.

Agreement – Everyone involved with a system is committed to improvement and agrees to jointly move toward goals while respecting and accommodating differences of opinion and approach.

Respect – Value, understand, and show consideration for people.


Principles

Change Management Principles

Kanban is structured to address the human tendency to resist change.

  • Start with what you do now – Understand current processes as they are actually practiced and respect existing roles, responsibilities, and job titles.
  • Agree to pursue improvement through evolutionary change
  • Encourage acts of leadership at every level

Service Delivery Principles

These principles acknowledge that organizations are a collection of interdependent services, and place the focus on the work, not the people doing the work.

  • Understand and focus on your customers’ needs and expectations
  • Manage the work; let people self-organize around it
  • Evolve policies to improve customer and business outcomes

Practices

The following practices are activities essential to managing a Kanban system.

Visualize

Kanban systems use mechanisms such as a kanban board to visualize work and the process it goes through.  In order for the visualization to be the most effective, it should show

  • where in the process a team working on a service agrees to do a specific work item (commitment point)
  • Where the team delivers the work item to a customer (delivery point)
  • Policies that determine what work should exist in a particular stage
  • WIP Limits

Limit work in progress

When you establish limits to the amount of work you have in progress in a system and use those limits to guide when to start new items, you can smooth out the flow of work and reduce lead times, improve quality, and deliver more frequently.

Manage flow

The flow of work in service should maximize value delivery, minimize lead times and be as predictable as possible. Teams use empirical control through transparency, inspection, and adaption in order to balance these potentially conflicting goals. A key aspect of managing flow is identifying and addressing bottlenecks and blockers.

Make policies explicit

Explicit policies help explain a process beyond just the listing of different stages in the workflow. Policies should be sparse, simple, well-defined, visible, always applied, and readily changeable by the people working on the service. Examples of policies include WIP Limits, capacity allocation, definition of done, and other rules for work items existing at various stages in the process.

Implement feedback loops

Feedback loops are an essential element in any system looking to provide evolutionary change. The Feedback loops used in Kanban are described in the Lifecycle section.

Improve collaboratively, evolve experimentally

Kanban starts with the process as it currently exists and applies continuous and incremental improvement instead of trying to reach a predefined finished goal.


Roles

Given Kanban’s approach to start with your existing process and evolve it, there are no roles explicitly called for when adopting Kanban.  Use the roles you currently have on your team.

There are two roles that have emerged in practice that serve particular purposes.  It’s highly likely that these functions are filled by someone in an existing role as mentioned below.

Service Request Manager

Understands the needs and expectations of customers, and facilitates the selection and ordering of work items at the Replenishment Meeting.  This function is often filled by a product manager, product owner, or service manager.

Service Delivery Manager

Responsible for the flow of work to deliver select items to customers.  Facilitates the Kanban Meeting and Delivery Planning.  Other names for this function include flow manager, delivery manager, or flow master.


Lifecycle

Because work items tend to flow through a kanban system in single-piece flow, and each system is different with respect to stages in its workflow, the best way to describe the lifecycle of the Kanban method is via the feedback loops involved.

Those feedback loops (cadences) are:

Strategy Review (Quarterly)
Select the services to provide and the context in which those services are appropriate.

Operations Review (Monthly)
Understand the balance between and across services, including deploying people and resources to maximize value delivery

Risk Review (Monthly)
Understand and respond to delivery risks in services

Service Delivery Review (Bi-Weekly)
Examine and improve the effectiveness of a service.  This is similar to a retrospective that is focused on improving the kanban system.

Replenishment Meeting (Weekly)
Identify items that the team will work on and determine which work items may be selected next.  This is analogous to a planning meeting for a sprint or iteration.

The Kanban Meeting (Daily)
A team working on a service coordinates their activities for the day.  This is analogous to a daily standup.

Delivery Planning Meeting (Per Delivery Cadence)
Monitor and plan deliveries to customers.


Origins


Primary Contributions

The Kanban Method formalized the flow approach to knowledge work and offered a means for organizations to improve their software development processes and adopt agile values and principles without first having to undergo substantial cultural change.


Further Reading

Personal Kanban; Mapping Work, Navigating Life by Jim Benson and Tonianne DeMaria Barry

Essential Kanban Condensed by David J. Anderson and Andy Carmichael

Lean from the Trenches: Managing Large-Scale Projects with Kanban by Henrik Kniberg.

Kanban and Scrum Making the most of both by Henrik Kniberg and Mattias Skarin

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now