Kanban for Skeptics

Nick Oostvogels, https://www.skycoach.be, @NickOostvogels

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, seem 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 [1].

This is why I wrote a free e-book 'Kanban for Skeptics' [2], 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 help 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 on the principles of Kanban [3]:

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. 1. Visualize workflow
2. 2. Limit Work In Progress
3. 3. Manage Flow
4. 4. Make Process Policies Explicit
5. 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.

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 all 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 on 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, they 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.

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.

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.

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

Off 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.

Free e-book

You can read about the other 4 arguments against Kanban by downloading my e-book for free at leanpub.com/kanbanforskeptics and automatically get next versions in the future.

References

1. Womack, James P. & Jones, Daniel T. Lean Thinking: Banish Waste and Create Wealth in Your Corporation. NY: Free Press, 2003.
2. https://leanpub.com/kanbanforskeptics
4. Goldratt, Eliyahu M. & Cox, Jeff. The Goal: A Process of Ongoing Improvement. Boston, MA: North River Press, 2004.
5. Classes of Service, Dennis Stevens (deleted blog)

---

More articles on Kanban

Aspects of Kanban

Making Your Culture Work with Agile, Kanban & Software Craftsmanship

Open Source Kanban Tools

More Agile, Lean and Kanban Resources

Scrum Expert

Agile Videos and Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Summer 2014 issue of Methods & Tools