what is kanban and why is it used

This post is first in a series about Kanban and how to get the most benefit from it. We will start with what Kanban is and explore why people use it. We will then look at to get started with Kanban and ultimately get the most benefit from the technique. If you are new to Kanban or just need a refresher on the basics, this is a great place to start.

Kanban is actually pretty simple and yet sublime. It is simple because there are very few rules, principles, practices or other guidance. Because it appears simple, many people don’t take it seriously or use it correctly. By doing so, they undermine the effectiveness of Kanban and the potential benefits that they could achieve.

Kanban is also sublime in that it can be a very powerful technique for organizing and completing work within organizations.

So let’s dive right in and get underneath the covers with Kanban.

What is Kanban?

Kanban is a signaling system that has usage dating back to Japan in the 17th century. However, it is probably best known as a scheduling tool to support lean manufacturing and just in time inventory as pioneered by Toyota Motor company in Japan in the 1950’s. Since then, it has been used to drive continuous improvement and reduced inventories in manufacturing plants worldwide.

The Kanban concept from manufacturing has been applied in the last 20 years to teams and departments doing knowledge work. It is frequently used with technology teams to build technology solutions. It has also been applied to other types of knowledge work including customer service, marketing and sales, finance and legal.

The Kanban Method was created by David Anderson in 2005 based on this application of Kanban to knowledge work. Anderson incorporated the work of W Edwards Deming, Eli Goldratt, Peter Drucker, and Taiichi Ohno into Kanban which is based on pull systems, queuing theory, and flow.

For the purpose of this post, we are using the term Kanban to include the Kanban Method and other applications of Kanban to knowledge work.

Kanban is often used to implement agile ways of working. In fact, after Scrum, Kanban is the second most popular agile approach used, as shown in this chart from the 2020 Digital.ai, 14th Annual State of Agile Report. Between straight up Kanban and Scrumban (Kanban plus Scrum), they total 17% of all survey respondents.

Kanban popularity shown in Digital.ai 14th Annual State of Agile Report

The Principles and General Practices of Kanban

The application of Kanban to Knowledge work continues to evolve and I would expect it to continue as people apply it and learn. Today there are four principles and six general practices of Kanban:

4 Kanban Principles:

  1. Start with what you are doing now
  2. Pursue incremental, evolutionary improvement
  3. Initially, respect current roles, responsibilities, and job titles
  4. Promote leadership at all levels of the organization

6 General Practices of Kanban:

  1. Visualize Your Work
  2. Limit Work in Progress (WIP)
  3. Make policies explicit
  4. Manage flow
  5. Implement feedback loops
  6. Improve collaboratively, evolve experimentally

6 general practices of kanban

Let’s take a closer look at these starting with the four Kanban Principles.

4 Kanban Principles

Principle #1 – Start with What You Are Doing Now

This first principle is to start where you are. Rather than making changes right out of the gate, Kanban suggests that you begin with your current processes and people. With Kanban, you don’t need to train everyone on a new way of working; you can simply start where you are and evolve.

For example, if you are currently not meeting in a daily standup, then continue to not meet daily. If your current process is for all the standards in your group to be drafted by Mike, reviewed by Suzie and then sent to legal for approval, then that is the process you should continue to use.

This makes Kanban a lot less threatening than other agile frameworks like Scrum or SAFe. Those frameworks require you to make changes which can be significant. For example, when you implement Scrum, you will introduce a sprint cadence, a host of new meetings and three foreign roles. That can alienate some people.

Principle #2 – Pursue incremental, evolutionary improvement

Continuing with the ‘low threat’ theme, this second principle says to pursue incremental and evolutionary improvement. Translation? Make small changes that meet with minimal resistance.

By focusing on continuous improvement and small changes, over time you will get big changes. Or at least impactful changes.

Principle #3 – Initially, respect current roles, responsibilities, and job titles

And more on the ‘low threat’ theme…don’t threaten people’s job security. Those existing processes, roles, responsibilities, and titles may have value. Respecting them means that we lower any possible resistance due to fear of change or job loss.

Don’t underestimate the fear of change or especially the fear of job loss! Job security ranks right up there with other basic needs.

Principle #4 – Promote leadership at all levels of the organization

This particular principle has evolved over time. The intent is to enable leadership from everyone. It also means, those closest to the work should take the leadership role in deciding how the work gets done.

Traditionally those highest in the organizational hierarchy were responsible for leadership. And this has led to a separation of roles into “doers” and “thinkers”. That doesn’t seem very efficient or effective does it?

6 General Practices of Kanban

1. Visualize Your Work

The very simple idea of visualizing work turns out to be really powerful. In fact, I would argue that in most organizations, the work isn’t visual at all. Much of the work actually being done in organizations is hidden. And I would wager that most of that hidden work is stuck waiting.

Visualize applies both to the work itself, or the “work items”, and to the actual steps that the work goes through to get done. Each of those steps in your process flow represents an activity that is performed to add value to the work.

Visualizing can mean that you add each work item or request to a big whiteboard in a public area. More frequently it means using some sort of online tool such as Jira, Trello or Leankit. While the physical boards are hard to beat because they radiate information, the online tools allow remote or distributed teams to work together and aid in tracking various Kanban process metrics.

In addition to seeing the work, you can also begin to see the business risk associated with the work items. This would include delivery dates, rework or quality issues, and relative priority of the requestor.

2. Limit Work In Process

Limiting work in process can be counter-intuitive. It may feel like we can get more things done by getting more things started. In fact, starting fewer things will allow us to finish more. This is because of basic math, the cost of context switching, and the risk of changes being made to the request.

Basic math says that for a given amount of capacity, more things started means everything takes longer. Would you rather have one thing completely done or five things started but only 20% done? There is economic benefit of one item being done. Five things 20% done represent waste. We will look at this particular item later in Part 3 when we explore Little’s Law and WIP limits in more detail.

And then there is the overhead of switching back and forth between things.

You could make the argument then that the smaller the number of things in progress, the faster things get done. Extend this to its logical conclusion and you would have a single item in progress.

Finally, there is the cost of rework that occurs when something is started and the request is changed. The change could be any number of reasons though a change in the requestors needs is the most common. The longer an individual piece of work is in progress, the higher the likelihood that the requestor need will change and that will result in rework.

Kanban systems typically restrict work in progress using a pull system. This means that work flows through the Kanban board by being pulled from the downstream step.

Limiting WIP might result in some people not being fully busy. This often alarms managers who want to make sure everyone is fully busy or all resources are 100% allocated.

3. Make policies explicit

The idea of making policies explicit is simply to document the Kanban rules. For example, if all work items have to meet a certain set of criteria to be considered “done”, then those criteria should be spelled out. Or if a lower priority request should be sidelined to work on a client production problem, then that should be documented somewhere.

Making policies explicit also applies to the workflow. Make sure that it represents how you are actually getting work done. This may differ from the official or approved workflow. All development needs to have a peer review or manager review would be an explicit policy.

One of the main benefits of making policies explicit is that it creates safety and repeatability. The process is not ad hoc; it will follow rules of the road.

That may also be perceived as a negative if currently team members are allowed to set their own priorities or work on whatever they want. They may not appreciate that they are expected to drop their current pet project if they get a hot request from the VP of Marketing.

4. Manage flow

Managing flow is about focusing on the work itself. Flow is the throughput of work through the system; the amount of work actually getting done.

Many organizations try to manage people. They want and expect everyone to be busy, or said another way, they want 100% or more resource utilization. Don’t be distracted by activity levels! What would be better, making sure people are working or making sure the work is getting done? So the focus of managing flow is to ensure work is flowing through the system and getting done.

Bottlenecks that limit flow will quickly become obvious in a Kanban system. A bottleneck is the slowest point in the workflow which acts as a governor or limitation for all work. In every system, there will always be a bottleneck or a limiting point. So managing the flow by focusing on the slowest process will be a continuous job.

Managing also implies measuring. We cannot manage what those things we don’t measure. So we measure the speed of the flow as well as the smoothness or predictability of the flow. Smoothness or predictability may be measured using frequency distribution histograms or scatter plots. We will look at measures in more detail in Kanban Part 4.

5. Implement feedback loops

Feedback loops are a vital part of Kanban. We use feedback loops to tell us if the things we do are effective or are making an impact. We connect downstream processes with upstream processes, something that may be a revelation for both groups.

6. Improve collaboratively, evolve experimentally

Collaboration is a key aspect. We should discuss what improvements we want to make and use those to evolve our way of working. We want to apply the Shewart cycle of Plan -> Do -> Check -> Act.

Why is Kanban Used?

Kanban is used because it works. It is powerful, yet simple and it is non-threatening and easy to introduce.

Simplicity – One reason for Kanban’s popularity is that it is simple and efficient. There aren’t a lot of rules beyond the 4 principles and 6 core practices, which makes Kanban easy to learn. Teams can decide to use Kanban and get started with little or no training.

Flexibility – Kanban is also very flexible. What started as a tool to help minimize inventory in manufacturing has been applied to software development, food preparation, support and numerous others.

Companies can tailor Kanban to their specific needs, workflows and even to their culture. They can scale up or scale down, and they cane be extended to include upstream or downstream workflows.

Alignment – Another key benefit of Kanban is that it can lead to alignment. Kanban helps groups of individuals to think and behave as one team that is aligned on common objectives. They see the big picture and have tools to evolve and improve it.

When Kanban is first introduced in organizations, one of the first things that people see is how disconnected and disjointed their collective work is and how complicated the flow of work has become.

Continuous Improvement – Kanban brings a continuous improvement mindset. Kanban provides the visibility to the work and encourages those people closest to the work to acknowledge bottlenecks and constraints and to work together to improve. Those bottlenecks and constraints are the points where teams have the most leverage; that is, their return on investment will be highest if they focus on the bottlenecks.

Kanban teams don’t accept the status quo. They are continuously looking for small improvements that will make a change for the better. To enable that, they use feedback looks and the collect hard data on how they are performing. This helps them to make good decisions on the next experiment to try.

Focus – Though Kanban doesn’t dictate that people focus, it supports the idea of having less things in flight at once. This allows team members to focus on the task at hand and not jump from one thing to another like a caffeinated squirrel.

Humans just aren’t great at juggling multiple things. The idea of multi-tasking is a bit of a myth – what happens is not so much doing multiple things at once as rapidly switching between tasks. This context switching causes delays and cost. Many studies have been done that prove the costly effects of multi-tasking; Wikipedia estimates that the cost of multitasking on US business was $650Billion in 2008.

One other thing about focusing – it helps us to get more things done. And that usually feels pretty good.

Low Threat – As noted in the discussion of Kanban principles, Kanban doesn’t represent much of a threat to the status quo. After all, they principles say to start with whatever you are doing today and to respect existing titles, roles and responsibilities. This is a big benefit for Kanban since it can be sued to introduce agile ways of working without triggering a strong resistance. This has sometimes been referred to as stealth agile.

Originally published here.