What is the Kanban Method?

By Jonathan Lin | Monday, Mar 2, 2020 in Articles

As opposed to kanban (small k), the Kanban Method (capital K) is a derivative of kanban when applied to knowledge and intangible work, where work is not quantified by the production of parts in the manufacturing sector.

5 Core Properties

In his book, Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson writes about the 5 Core Properties of the Kanban Method, which have emerged from his own attempts to create “lean behavior” in organizations.

Visualize the Workflow

Visualizing the workflow is often done with the help of a kanban board. This board may be either physical or virtual. Often the work item represented by a card (sticky note, card, etc.), and the cards move through a series of columns that represent the status of the work.

Visualizing the workflow has the benefit of not needing to ask a team member about the status of a piece of work. Gone would be the days where you would ask about a work item via email or Slack (as long as everyone has the understanding that updating the Kanban board is a paramount duty!)

Visualize the workflow in a kanban board.

Limit Work-in-Progress (WIP)

It may seem counter-intuitive, but starting work on more and more work items simultaneously as an individual or as a team has been proven to increase lead times (the amount of time it takes to complete a work item).

Limiting Work-in-Progress has the benefit of enabling more focus on particular tasks that have already been started, without spreading everyone out more thinly by starting more and more tasks.

Limiting WIP calls to attention stages in your kanban board that are over-committed and bottle-necked.

Measure and Manage Flow

Here are some example metrics that can help you along the process of continuous improvement:

  1. Lead Time is measured by elapsed time from start to finish (e.g. from when an order is placed to when the order is delivered)
  2. Cycle Time is the amount of time per unit (e.g. hours per video production, man-days per feature, etc.). Note that Lead Time and Cycle Time don’t have the same unit despite having “Time”. While it may seem these are rather the same things, Lead Time also includes non-productive time (e.g. time waiting for a part, time waiting for a remote team to respond, time waiting for the customer to reply, etc.)
  3. Total WIP is the total number of cards that are currently in progress in the process.
  4. Blockers are the number of cards that are currently being blocked (and cannot progress in the process)
  5. Throughput is the number of cards completed in a period of time (e.g. cards per day, cards per week)

There are many other (advanced) metrics that can be explored, but be sure to start off simple! We will cover these advanced metrics in another blog post.

Make Process Policies Explicit

Process policies are explicit rules that govern how work is added, what is being worked on, and how work is moved from stage to stage towards completion.

Some examples of explicit process policies are: - Tests must be added (where possible) after feature development is complete before it is handed over to QA for testing, in order to reduce defects and rework. - A work item runs into a blocker, no progress can be made but WIP limit has been reached. How can we decide whether or not more work can be started in the meantime? Who is the person to talk to about this? - The sales manager is requesting for an “urgent” feature in order to close a sale. What is the policy for prioritising this work? Who can give the authorisation? - While work is already ongoing, developers have new ideas about how to improve the feature, but it was not part of original planning. How can scope creep be avoided, and how can the team keep to the definition of done?

The lack of explicit process policies can cause all the benefits of the Kanban method as aforementioned to be thrown out of the window. Thus, making process policies explicit is paramount to ensuring that reasonable process checks are in place to prevent a complete overrun of work.

Improve Collaboratively

This property is originally described in David’s book as Use Models to Recognize Improvement Opportunities. However, it is not immediately clear from the book about what models to use.

However, it is clear that team should improve on the process together, once they have a kanban board set up and running.

Use KanRails to Visualize and Optimize your Processes!
Try KanRails For Free