Kanban System

A Kanban System is a delivery flow system that controls the amount of work in progress using visual signals.

The visual signals are known as kanbans. They regulate the amount of work entering the system based on system capacity, thereby improving the flow of value to customers. The kanbans, and the policies associated with them, create a pull system, where work is “pulled” into the system when other work is completed, rather than “pushed” when new work is requested.

As we explain in a previous article, Kanban was the method developed by Taiichi Ohno to enable Just-in-Time (JIT) production in Toyota. The essence of Kanban was later on adopted by the software industry to improve agility in what is known as the Kanban Method.

Now, let’s focus on software development and digital product management. Here, we are generally talking about virtual kanban systems.

Kanban System

I often meet people who say they are doing Kanban but when I see what they are doing I realize they are using just a board with stickers. This is what we call a proto-kanban or just a board with stickers 🙂

The difference between a Kanban board and a Kanban system is that the Kanban board is just one component of the Kanban system, the visualization part. But, there are several key components we need in order to have a real Kanban system.

The key difference are the norms and policies governing its behavior:

• When must we replenish?
• When must we deliver?
• How do we manage dependencies?
• How do we manage demand? And, so on.

A Kanban System is a system of work that manages how a service within an organization plans, executes and delivers value and continuously improves. Therefore, there must be some rules in addition to the visualization of the work and the process.

The Kanban Method

The purpose of the Kanban Method is to design and implement Kanban systems to improve service delivery agility at service level and to improve business agility at organizational level to ultimately drive evolutionary change.

Supported by the Kanban values and guided by the Kanban principles we implement a Kanban System to improve our service.

The Seven Core Components of a Kanban System

There are seven core components of a Kanban System. If just one of them is missing or not adequately implemented we will not get the expected benefits from the adoption of the Kanban Method as our work system:

1. A service
2. A workflow
3. Work types
4. Visualization policies
5. Way-of-working policies
6. WIP policies
7. Meeting policies

Now, let’s see in more detail those components that are usually missing in many Kanban implementations, besides de Kanban Board.

1 – A Service

You can only improve something that you manage and you are responsible for. And, this is exactly where most of the difficulties in Kanban adoption begin – the inability to define the boundaries of the Kanban System.

First of all, we need to understand what is the purpose of our service and what are the boundaries of our service delivery. Where and who we get work from and where and who we deliver work to.

Those limits define the commitment point and delivery point. Outside these two points we can still visualize the workflow but it is not within our responsibility and therefore we cannot improve it or reach compromises on its performance.

In addition to defining upstream and downstream boundaries we need to clearly identify and manage dependencies.

All set to go! We understand our mission and goals, we have a clear understanding of the upstream and downstream boundaries of our service and we have identified other services (internal or external) we are dependant on.

2 – Workflow

Now, we must model our workflow. And, it is very important to insist here that we want to model how we are currently working, not how we think we are working or how we would like to be working. This is extremely important!

The Kanban principle of starting with what we do now is of utmost importance here. We need to model and visualize what we do, understand demand and current capabilities of our service and then seek evolutionary change. You cannot improve if you don’t understand what you are doing.

One of the great discoveries of my professional career is to come to realize to what extent people don’t have a clue how they are working within their teams or organizations. Hence, the importance of the value stream mapping technique from Lean.

Here, the principle is the same as we apply in value stream mapping; we want to visualize all the steps the work follows from the moment it enters the kanban system until it leaves it.

My recommendation here is that you err on the side of detailing as much as possible rather than defining an overview of your workflow. In other words, if your workflow is TO DO – IN PROGRESS – DONE you should think harder 🙂

3 – Work Types

Have you ever tried to go to a pizzeria to order a hamburger? What do you think would happen? Well, that’s what many teams and services do in lots of companies. They don’t know what type of work they do so they just accept anything.

Identifying work types is usually a straightforward job as teams just need to analyze last few weeks or months of work and categorize it.

Here, you must find a balance between too much detail and too little detail. For example, if you are a coffee shop, you probably don’t want to categorize all possible combinations of coffees people might want, but on the other hand you don’t want to have just two categories: coffee and tea.

You must find the right balance and make sure that you visualize at least 80% of what your service does.

In addition to the types or work you must identify the risk profile of the work, or the class of service. Because different types of work might be going through a different workflows or having different priorities.

For each work item in your kanban system, please, identify the following:

• Source of work
• Size of work
• Outcome of work
• Flow of work
• Risk profile of the work (Class of Service)
• Relevance to service’s mission

4 – Visualization Policies

For a Kanban System to work properly and deliver the expected benefits we must visualize everything. We must visualize work item types and thier design, classes of service, workflow, ready to pull criteria, dependencies, blockers, service delivery performance, system health metrics, objectives, and more.

We must agree on how to visualize work in order to understand what is going on and take appropriate smart decisions and as a result we will have a list of policies governing the visualization of the workflow.

For your Kanban System, please, at least define the following visualization policies:

• Work types
• Work item design
• Workflow
• What work not to visualize
• How often must the visualization be in sync?

That’s the basic list, but as I said at the beginning of this section, we expect more visualization policies as we improve in our understanding and implementation of Kanban.

5 – Way-of-Working Policies

The team must agree on how to handle the work, so that all team members handle work in a consistent way. What do we do if someone orders a hamburger but we are a pizzeria, what is the procedure for dealing with cancellations or urgencies? Are all customers equal?

In my experience, lots of confusion, arguments and even personal conflict comes from not agreeing on how to work together. And, this is not just about the flow of work, but also about communication, conflict resolution or roles and responsibilities.

So, if you want to prevent waste and design a sustainable and performing kanban system you must make explicit how you work together, from the policies governing the intake of work to the norms determining how to solve blockers and impediments.

The minimum set of policies you should define for your kanban system are the following:

• How to manage demand
• How to deal with side orders (Dark Matter)
• When to pull
• Part-timers
• Other policies (may have been defined previously, but just in case)
  • Definition of Done
  • Definition of Ready
  • Blocked Items
  • Urgent Work
  • Due Dates at Risk

6 – WIP Policies

Explicitly limiting WIP is key to enable pull in a virtual kanban system. But, this is also one of the biggest impediments and resistance we usually find when implementing kanban in a team or organization.

In my experience, all organizations have more work in progress they are capable of managing sustainably, so we need to reduce WIP drastically.

In early kanban adoptions WIP is limited for the whole kanban system. As team evolves, they establish WIP limits by activity and also by class of service.

The two things you must do here are:

• Discuss where to set explicit WIP limits
• Discuss what to do when a WIP limit is violated

In my experience as Kanban consultant, it is not until WIP limits are so low they start hurting that the real conversations occur that will provoke improvements in the kanban system.

7 – Meeting Policies

The Kanban Method recommends seven cadences (or meetings). And, again, it is very important that you agree on what meetings are you going to do, who must attend and what must be discussed.

For each meeting define:

• Purpose of the meeting
• Attendees
• Place and Time
• Agenda
• Required input information
• Expected output information
• Roles during the meeting (i.e. facilitator, secretary, owner, …)
• What happens after the meeting

Kanban System Summary

I hope that I could effectively explain the difference between a board with stickers and a Kanban System.

The good thing about the Kanban Method is that it is not very prescriptive and not disruptive at all. A Kanban adoption always starts from where the organization is and seeks to improve by implementing Kanban System across the organization for each service.

The bad thing about the Kanban Method is that it forces humans to make everything explicit and visual, and to limit work-in-progress. And, that’s quite difficult in many organizations.