Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Introduction to Kanban

Scott Ambler is chief methodologist/Agile and Lean for IBM Rational.

In This Issue

  • Introduction to Kanban
  • Take the "State of the IT Union" Survey and potentially win a copy of "Innovate the Future" by David Croslin.
  • Hot Links

Introduction to Kanban

Kanban is a lean method which has taken the agile community by storm the past year or so. Dr. Dobb's has examined the method in Experiences with Kanban, and David J. Anderson's long-awaited book (long awaited by me at least) KANBAN: Successful Evolutionary Change for Your Technology Business was recently released by Blue Hole Press. In a nutshell, Kanban describes a strategy for IT departments to systematically improve their approach to solution delivery based on lean and agile strategies.

Kanban is Japanese for "signal card", in physical systems the card is associated with a single piece of work to indicate where that work is in the overall process. In software delivery, due to its virtual nature, each kanban represents a single piece of work (a nuance). Either way, the number of kanban available is equivalent to the agreed to capacity of a system/process. New work can start only when a card is available, and a card becomes available only when a previous piece of work is complete, implying that new work must wait in queue until existing work is complete. This is known as a pull system because work is pulled into it by the people performing the work, instead of a "push system" where someone or something outside of the team pushes work into the system.

The Kanban method is a collection of principles and strategies which exhibit those principles. Kanban is arguably even more nebulous than Extreme Programming (XP), a collection of values, principles, and practices and certainly more nebulous than Scrum which prescribes a lifecycle, several roles, a handful of practices, and a collection of philosophies. Kanban starts with the existing workflow and process which are in place and then improves things from there -- the primary implications are that Kanban can be applied in more than just agile situations and that it's potentially simple to adopt. The heart of Kanban is to limit work in progress (WIP) and to pull work through the team via visual signaling. Kanban also promotes both agile and lean strategies to streamline the overall process; small batch transfers to reduce lead time; prioritization by value to maximize return on investment (ROI); managing risk to increase your chance of success; making progress based on imperfect information (just good enough gets the job done!) to reduce time to delivery; responding to change to increase your likelihood of delivery something of value; and building a high-trust environment to improve collaboration amongst everyone involved.

Kanban software development teams follow five principles:

  • Visualize workflow. Teams will use a Kanban board, often a physical whiteboard or corkboard although electronic boards can also be used, which displays kanbans which indicate where in the process a piece of work is. The board is typically organized into columns, each one of which represents a stage in the process or a work buffer or queue, and optionally rows indicating the allocation of capacity to classes of service. Each kanban should have sufficient information, such as the name and ID of the work item and due date (if any), to enable project-management decisions by the team without the direction of a manager. The goal is to visually communicate enough information to make the process self-organizing and self-expediting at the team level. The board is directly updated by team members throughout the day as the work proceeds, and blocking issues are identified during daily stand-up meetings. This is one difference between Kanban and agile methods such as Scrum -- where Scrum suggests you focus both on blocking issues and status issues (such as who did what yesterday and what they think they'll do today) Kanban focuses on the high-value blocking discussions only.
  • Limit work in progress (WIP). Limiting work in progress reduces average lead time, which improves the quality of the work produced and thereby increases overall productivity of your team. Reducing lead time also increases your ability to deliver valuable functionality frequently, which helps to build trust with your stakeholders. To limit work in progress you need to understand where your blocking issues are, and then address them quickly, and to reduce queue and buffer sizes wherever you can. There are some interesting tradeoffs: although buffers and queues add WIP, and therefore increase lead time, they also smooth over the workflow and increase the predictability of lead time. The implication is that because every team is different, you will have different WIP limits that you'll need to set and then evolve yourself based on empirical results from experimentation.
  • Measure and manage flow. Kanban teams produce valuable solutions to the business in a steady flow, not just as a project at a time. One aspect of achieving this is that you need to understand the demand profile of the organization that you're supporting so that the Kanban process design can reflect the different demands for different types of work. For example, are there seasonal differences in the way that requests for new features arrive? Do you need to support legislated requirements? Is your team responsible for addressing production problems, some of which may be immediate? Do you need to support requirements with fixed delivery dates? Do you need to support "expedited requirements" which are very high priority? The implication is that your Kanban system may need to support several classes of service to be effective.
  • Make process policies explicit. A Kanban team will define policies around WIP, prioritization (replenishment of the work queue), delivery cadence, lead time for given classes of service, and how issues will be addressed/escalated to name a few. These policies must be explicit, reflect the situation which the team faces, known to both the team and their stakeholders, and sufficiently malleable so that they can be evolved over time.
  • Use models to recognize improvement opportunities. Kanban teams should reflect on, and then improve, the process which they follow. A common technique popularized in the lean software development books written by Mary and Tom Poppendieck is called value stream mapping, a process modeling technique which focuses on identifying value-added activities and the wait times between such activities. This fairly simple technique enables you to visualize which aspects of your process are wasteful and therefore candidates for improvement.

In addition to the five principles, Anderson describes several very interesting philosophies which I feel are important to truly understand Kanban.

  • First, the main reason to adopt Kanban is improve your existing software delivery process -- it isn't to do a revolutionary overhaul through the adoption of new processes, but instead to build on your existing environment which is already working (albeit not perfectly) and make it better. The belief is that it is better to optimize what already exists because it is easier, faster, and will meet with less resistance than introducing a "radical" change.
  • Second, processes need to be adapted for each specific situation because people are unique, teams are unique, organizations are unique, and the situation which a team finds itself in is unique. This is a philosophy that I've promoted myself over the years, and which I've been focusing lately on with my work on the Agile Scaling Model (ASM).
  • Third, frequent releases provide concrete visibility into the progress of a team and thereby builds trust with their stakeholders.
  • Fourth, Kanban asks to business to engage collaboratively with the development teams, something that I promote with Agile Modeling's practice of active stakeholder participation, and not just with a stakeholder surrogate such as a business analyst or product owner.
  • Fifth, Kanban teams engage in a long-term service provider relationship with the business, you don't create a Kanban team for a single project and then disband it, and as a result they are committing to a long-term relationship instead of a short-term piece of work.
  • Sixth, the true measure of success is business value delivered, not just working software, bringing a greater and more mature focus on delivering consumable solutions.

There are several important differences compared with agile strategies.

  • First, Kanban dispenses with the concept of iterations (also known as "sprints" or "time boxes") in favor of a continuous flow of work. This in turn also decouples the cadences of several common activities or events such as work prioritization, development, reflections, and delivery. For example, you may choose to have a work prioritization meeting every Monday morning, an internal demo every second Wednesday afternoon, a reflection/retrospective meeting on an as needed basis, and release into production on the first business day of alternate months.
  • Second, Kanban teams pull work into the system in different classes of service. This reduces some of the bureaucracy inherent in mainstream agile methods such as Scrum because it gets rid of the estimation overhead for most classes of service while at the same time focusing resources on continuous delivery of your solution. This continuous flow of delivery increases predictability, reducing the business risk associated with the effort, which in turn leads to greater trust in the team.
  • Third, the combination of explicit policies, transparency, and visualization empowers team members to understand the overall process, to make their own decisions, and to manage risk. As a result Kanban teams are not only self-organizing they're also self-expediting.

So why should you consider Kanban? An important benefit of Kanban is that it provides simple mechanisms for teams to flush out issues that impair their performance, motivating them to focus on addressing the actual problem instead of on symptoms of the problem. Kanban also makes blocked work items explicit to everyone on the team, and because it isn't easy to ignore blocked items team members with slack time are motivated to swarm over a problem and address it quickly to remove the block. Kanban provides transparency into both the work and the process, showing how work is passed from one group to another and thereby improving understanding and teamwork. This helps teams to organize themselves more effectively and provides senior management with the visibility required to govern effectively (if they choose to take that opportunity). Finally, the combination of improved flow and quality shortens lead times, which in turn improves performance and predictability. Improved performance and predictability increases your ability to treat IT like a business instead of an opaque morass of unfulfilled promises.

The observation that I want to leave you with is that Kanban isn't paradigm specific. In other words, it can be used to improve the strategy followed by agile teams, but traditional teams, and potentially even ad-hoc teams. The majority of organizations have teams following different processes, or at least different tailorings of the same base process, and Kanban may provide a common way for them to make systemic improvements across the board.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.