As a change agent, you constantly need to reassure people that the path we follow is worthwhile traveling. This need is often expressed in the form of critique and difficult questions. When I coach teams, this is often the case. The same thing happens when introducing Kanban.

However, I noticed that Kanban raises much harder questions on a management and leadership level, once people are introduced to the basics and start to explore the subject on their own. The type of questions Kanban raise seems to be hard to answer without lapsing into hour-long discussions. This is normal because Kanban is a change management approach, not a methodology, and therefore much less prescriptive. In order to provide reassurance, as a coach, you need to trace the questions all the way back to the principles of Kanban, which are grounded in Lean thinking

This is why I wrote a free e-book 'Kanban for Skeptics, that lists the 5 most common arguments against Kanban.

What is Kanban?

When the term Kanban is used in the field of software engineering, people think it is only the practice of adding Work In Progress (WIP) limits to the different stages in a development lifecycle.

In theory, Kanban is a change management approach that employs a WIP-limited pull system.

The limited set of rules and principles helps people focus on customer value and avoid stacking up half-finished work, which is still a common issue in the software industry.

David Anderson has written a nice summary of the principles of Kanban:

First, follow the foundational principles:

Start with what you do now
Agree to pursue incremental, evolutionary change
Initially, respect current roles, responsibilities & job titles

Then adopt the core practices:

1. Visualize workflow
2. Limit Work In Progress
3. Manage Flow
4. Make Process Policies Explicit
5. Improve Collaboratively

But because Kanban is not a process, people will perceive the change differently. In day-to-day life, the way they work won't change much, in the beginning. The only things they will feel in their day-to-day job are the principles that employ a WIP-limited pull system. These will slowly introduce different behavior and continuous improvement.

5 common arguments

In my e-book Kanban for Skeptics, I explore 5 common arguments against Kanban.

We lose our ability to plan.
It will take longer.
Things will get stuck, we can't keep WIP limits.
Stakeholders don't care about feeding the flow.
We will lose team cohesion.

Although these arguments are invalid, we must acknowledge them as challenges for all leaders trying to introduce Kanban in organizations. My e-book will help you get the discussion started.

Let's explore one of the arguments.

Things will get stuck, we can't keep WIP limits

Work In Progress (WIP) limits visualize the maximum capacity of each stage in the value stream. If a WIP limit of 3 is set on the development column of the Kanban board, this means the developers can't work on more than 3 tasks simultaneously.

Kanban for Skeptics

When people hear about the concept of Work In Progress limits, their first reaction is that it will never work in their organization. They expect a major efficiency drop if they would apply it to the different workflow stages. "Our testers can never keep up with the pace of our developers when testing the features. Developers would be idle for half of the time". This is applicable to all different roles in the organization all the way up from sales to operations downstream.

The way most organizations fix this is by working asynchronously. When testers are looking at the features, development is starting to work on new requests, to maximize their efficiency.

Remember that Kanban doesn't focus on maximizing resource utilization. Instead, it focuses on maximizing end-to-end flow efficiency, which is a completely different goal.

Improving flow

The focus of Kanban on end-to-end efficiency all points towards pulling value from the customer with as much added value as possible. So instead of maximizing utilization rates, the team focuses on getting value through the flow as quickly as possible. In some cases this may cause people to be idle, making sure they are not working on things that cause an increase in work in progress and the risk of a value mismatch.

Instead of blindly starting to produce as much as possible, the team focuses on improving the flow by removing bottlenecks [4] and redesigning the flow in order to keep up with the new stream of demand. This is an exercise that never stops, due to the variability in the consumer market. Thanks to the clear focus on end-to-end flow, the team makes sure they keep working in a pull system, driven by customer demand.

If we're honest, we all know that it's in our nature to start looking for new challenges when the major problem-solving of a task is done. This leads to a huge pile of tasks that are only 90% finished. The end-to-end focus of Kanban will push you to finish the remaining 10%.

There is no exact science in determining WIP limits. As soon as they are chosen, bottlenecks will appear. This doesn't have to be a disaster. When the organization embraces the idea of a pull system, it will understand that WIP limits help to improve end-to-end efficiency. The first signs of a bottleneck appearing will drive continuous improvement. People will start to get nervous because they can't pull a new feature to work on.

It will drive team members to collaborate on 2 levels. A first reaction will be to go out and check what the problem is. Why are you stuck? Can I help you to get going again? This will eventually get the flow going again, but soon things will get stuck again, leading to the second reaction. How can we solve this bottleneck? If you think about it, the WIP limits cause the team to self adjust to changes that affect the end-to-end flow.

Emergencies

Another common remark is "We're not able to keep WIP limits because of emergencies that pop up from time to time". In a well-balanced flow, all stages in the Kanban flow are close to their WIP limits. This means that when an emergency pops up, the team won't be able to start solving it until new capacity becomes available. This is not acceptable because an emergency can't wait for half a day before someone starts working on it.

Kanban for Skeptics

Reality proves to be different, even in Kanban land. When an emergency arrives, it needs to be dealt with, immediately! This means WIP limits can be broken. How- ever, the decision needs to be made very consciously because of the impact.

Introducing an emergency into the flow causes people to drop what they're doing and switch context. This comes with a cost. The flow will be interrupted and lead times will be impacted. You probably understand that it's important to reduce these interruptions to a minimum. Otherwise variability of the Kanban flow will increase, tearing down its reliability and frequent delivery of value. It doesn't take long before you fall back into estimating and planning.

One way to reduce the number of emergencies that interrupt the flow, is by making sure new items are pulled from the queue on a regular basis. When on average, it takes only 2 hours for a feature at the top of the queue to get pulled, far fewer emergencies need to be pushed into the flow. When you can rely on the pull frequency of the Kanban flow, it's much easier to just prioritize it in the queue instead of interrupting everybody's work.

Kanban for Skeptics

Off course there will always be emergencies that need to be dealt with immediately. This is where the concept of Classes of Service [5] can offer you some flexibility. By categorizing the type of work that enters the Kanban flow, we agree to the service levels that apply to these different categories. Some categories have much higher due date performance than others. This gives you some room to absorb variation because of emergencies that disrupt the flow.

Many Kanban implementations use a fast lane to deal with emergencies. This is a horizontal lane that spreads across all workflow stages and has a WIP limit of it's own.

Kanban for Skeptics

When an emergency arrives, for instance the payment module is offline, it is pulled through the fast lane with priority over all other work items. This is often the case when you work on an existing product and critical issues can appear at any given time. At that point, the WIP limits will obstruct the hotfix that needs to be released as fast as possible.

By using a fast lane, we implicitly give an emergency priority over all other work in the flow. But to prevent the fast lane to disrupt the flow too often, we will also limit its work in progress, only 1 item can reside in the entire horizontal lane across all workflow stages.

Summary

Of course, introducing WIP limits is going to cause problems! The question is, why is that bothering you? The purpose of WIP limits is to make it easier to work in a pull system that is more effective from start to end. The WIP limits will signal an uneven balance in your flow. From that point, you can start working on improving it.