What is Kanban?

This post is co-authored by Excella Agile experts Paul Boos and Ken Furlong.  Ken will first address what Kanban is in the first portion of the post, while Paul will use the second portion to address some example situation where Kanban is especially useful.

What is Kanban?

In this blog post, we’re going to talk about Kanban (note the capital K). We’re going to refrain from defining it until later, though. The reason will become clear after some initial exposition.

To begin, Kanban (capital K) is based on kanban (lower case k). The latter is a workflow mechanism popularized and refined in Lean manufacturing and the Toyota Production System. Simply put, a kanban is a signal from a downstream person/team/system (let’s call it an ‘agent’) to an upstream person/team/system (agent). The signal tells the upstream agent two things:

1. The downstream agent has completed something. This completion consumed an input that the upstream agent provides.
2. Therefore, the upstream agent should produce a replacement input for the downstream agent so that production can continue.

Kanban (capital K) as used in the Product Development space has two principle tenets, both of which follow logically from the idea of a kanban (lower case k):

1. Visualize your workflow.
2. Limit work-in-progress (WIP).

Let’s unpack each of those.

Visualizing Your Workflow

Visualize your workflow means exactly what it says – create a visual representation or model of your workflow. There are different ways of doing this, such as creating a process diagram:

The most common and, in my opinion, useful, is a series of columns representing the progression of stages within a workflow. This is called a Kanban board:

Implicit in this tenet is that you also visualize the work within the workflow. This is why a Kanban board is a better visualization – it accommodates visualizing the work far better than a process diagram:

Kanban advocates visualizing your workflow for two very simple reasons:

1. Different people in the organization likely have different understandings of what the workflow is.
2. Visualization more effectively conveys information. You may read this and think “That’s silly. What difference would this possibly make?” I challenge you to try it. You’ll be surprised by the difference it makes to you and your colleagues.

Limiting Your Work in Progress

The second tenet of Kanban is to limit the amount of work in progress (WIP). The simplest way to do this is to put constraints on the number of work items that can be in a given stage simultaneously. These limits are also visualized on the Kanban board:

Limiting WIP is based on a similarly simple fact: having fewer things in progress simultaneously is almost always more effective and more efficient than having many things in progress. While a lot of folks intuitively believe that multi-tasking makes them more productive, it actually does the reverse. Interestingly, I say that multi-tasking is intuitive but the reverse is also intuitive. Imagine, for instance, you go up to the customer service desk in a retail store. Now imagine that the only clerk is helping 10 customers simultaneously. Intuitively, as a customer, you understand that it will be faster and more satisfying if they handled each customer one at a time. They wouldn’t spend some much time bouncing back and forth between different customers and would resolve each customer’s issue more quickly. For those who prefer data, there have been multiple studies in recent years proving that multitasking does incur a serious productivity drain.

Now that we have a basic understanding of Kanban, let’s turn it over to Paul to see some situations in which it is particularly useful.

When is Kanban Useful?

So, as Ken mentioned, this is a great way to visualize your work. With that basis, let’s continue on to where Kanban may be useful…. Essentially, you can use it in any place where continuous observation of the work system is beneficial. OK, I know that sounds general so let’s go with some specific examples.

1. Software Maintenance
Perhaps the place I have found Kanban most useful is in software maintenance activities. These are usually smallish pieces of development work that continuously stream in. It allowed me to start with what my system looked like and see where improvements could be made. This is the way I improved the maintenance activities at EPA’s Office of Pesticides. The advantage of visualizing the workflow allowed me and the team to identify and communicate to management where the real bottlenecks in our system were, as opposed to generalizations that maintenance development was too slow.

2. Managing Multiple Teams
If you happen to manage multiple teams; each team may have a similar workflow with slight differences. If you are interested in some common process metrics, the usual way is to force every team to use a standard process. This can sub-optimize the work being done by each team due to the differences in their respective contexts. If teams have deployed Kanban, you can get common metrics like lead time and throughput without demanding they all standardize their process. You can also quickly understand these subtle differences between teams and still understand their flow of work (even with the differences) as they are all visualized on their Kanban boards.

3. Improving on Scrum
Kanban can be helpful to put in place by a team using Scrum (so useful in fact that Excella is setting up a course about this). They can model the workflow occurring within each Sprint and then establish a Kanban board to visualize it. After doing so, process improvements can become more apparent. A frequent dysfunction is for a team to pull in too much work as soon as it starts an iteration. A Kanban board can really make this problem apparent as the team struggles through this. The team can then retrospect on what they see and establish the proper WIP limits for a consistent throughput.

4. Improving Collaboration
If you are a team ingrained with a traditional sequential approach and in particular one that relies heavily on specialists through this process, Kanban can provide a way to evolve to something more smooth flowing and collaborative. Leaving the process and roles in place and only breaking work down into smaller and smaller batches over time (effectively cranking down the WIP limit) can increase productivity. It can also increase collaboration with your customer since they get involved more often through each cycle of ever smaller and smaller batches.

5. Managing Continuous Intake
Any team or group that has a continuous flow of incoming work that follows a similar process each time can find this useful. Some of these may be help desks that analyze and respond to issues reported, back-end infrastructure activities (such as deploying environments), or DevOps development flow.

6. Providing Insight to Leaders
Also, when work is abstracted such that the flow is similar for different product development streams, such as can occur in a Portfolio of Epics or Features, Kanban can be very useful in understanding the performance of the system at a high level for executives and managers. They may suddenly realize having too many projects in flight in the organization is causing the equivalent of organizational multitasking of whole teams! Management may now see that limiting the number of projects they take on simultaneously can provide more focus on getting quality products out more rapidly.

This phenomenon of teams being able to improve their processes and work by visualizing their workflow and limiting their WIP finally brings us full circle to how we define Kanban. Ken could have started this blog post by defining it as “a workflow management framework based on Lean principles.” While that may have been accessible to people, it would have missed the deeper purpose and power of Kanban. Fundamentally, Kanban is a change management tool.

We hope you have found this post useful and we encourage you to learn more about it. Two great books to read are Kanban by David J. Anderson and Lean from the Trenches by Henrik Kniberg.