What'S the heck that Bottle­neck?

You should reduce time loss before you start thinking about speeding up performers' work. I mentioned this in the previous chapter.

These losses occur because each specialist in the production chain gets new tasks on their to-do lists too early.

Each stage has its own throughput and pace, and you should take that into account when you decide to give them another ticket. You should give them just enough at the time they need it.

How much do they need?

A short answer - as much as the system bottleneck can handle. And no more. Because it will be pointless.

What kind of bottleneck? We don't have that

Actually, you do. Every system that has a flow of work has a bottleneck. It's just a law.

A bottleneck is a resource that limits our system because the demand for that resource is greater than its capacity. There is no way to increase the performance of the whole system except by optimizing the bottleneck.

The only thing I want you to remember after reading this article is that the throughput of the whole system is limited by the throughput of the bottleneck.

How to find the bottleneck?

Usually you can intuitively identify the bottleneck if you have spent enough time working inside the system.

Or you can ask your team. Who do they wait on more often? That might be your first clue.

Or you can find it visually if you have a proper workflow visualization, such as a Kanban board. If not, welcome down the rabbit hole. You can start with part two of the book Making Work Visible. With such a visualization, you can identify a bottleneck (in most situations) as a place with the longest queue of work to be done. That's the second clue.

And ... that's it. I don't know of any other universal solution, but I think these two cover the vast majority of all possible cases.

Theory of constraints

or TOC for short - a concept invented by Goldratt and widely used in the American manufacturing industry. Later, David Anderson was inspired by these ideas to create his "Kanban Method" for IT.

If you want to learn more about this topic, I recommend starting with The Goal.

The book contains several ideas, but I will only discuss two:

Drum - Buffer - Rope

In the book, Goldratt uses the Boy Scout trek analogy to illustrate a chain of interdependent events.

One by one, the boys walk down a narrow path in the woods, trying to reach a destination as quickly as possible. There's Herby-the slowest of the boys. He knows he is slowing down the whole group, so he decides to go to the end of the chain to give the others the chance to go faster. But this doesn't lead to anything good. Because the goal can only be reached if the whole team arrives at the destination, not just the faster ones.

The steps to coordinate the team are

1. tie all members together with a rope to prevent the length of the column from increasing uncontrollably
2. make sure the length of the rope between the members has a small reserve ( buffer ) to prevent the whole team from stopping if someone suddenly decides to tie their shoes.
3. give Herby a drum to create a walking rhythm for all members

The five focusing steps

The original steps are in the book. I'll rephrase them a bit for our context:

1. find the bottleneck on your kanban board
2. do everything necessary to utilize the bottleneck by 100%
3. let the other work centers do just enough work to provide the bottleneck with a steady stream of work items, but no more than that
4. find ways to increase the capacity of the bottleneck (technological changes, headcount, etc.)
5. repeat

SOME IMPORTANT NOTES

1. For example, you've identified the bottleneck - that's part of the process where programmers write their code. Do not start optimizing the whole stage. Sometimes there is one person in the column who covers the lack of expertise of the whole team. Usually it's a technical lead who answers all the other developers' questions. And he/she is actually your bottleneck
2. When you see a lot of work in front of a column, it doesn't always mean it's a bottleneck. It could be those blocked tasks that have been pushed back and weren't marked in any way. In this case, it could mean that you have a poor quality in the previous stages
3. If you see a lot of work in the first TODO FOR BA column - it doesn't mean anything except the impatience of the stakeholders and the lack of WIP limits in that column

WIP-limits

WIP limits are a tool to limit your work in progress (sorry for the obvious). By using it on your Kanban board, you can regulate your workflow to reduce the waiting time. This tool helps to implement the third step of the The five focusing steps algorithm.

How to use it

1. First, set a limit for the In Progress of the bottleneck. Usually it's 1 work item per person. But if the execution of these items is systematically delayed or blocked by some dependencies, but these delays are predictable and short, you can increase this number to 1.5 or 2 work items per user, for example. And if this phase of the work involves some practices such as pair or mob programming, you should reduce the WIP.

2. Set a buffer for the bottleneck Set Minimum WIP limits for the buffer to prevent the bottleneck from running out of work to do. You can't afford to leave the bottleneck with no work items. Set Maximum WIP limits for the buffer to prevent overproduction.

3. Set other limits experimentally Start with the stages before the bottleneck one at a time (from right to left) and set WIP limits in the In Progress and TODO columns experimentally. Don't set the limit too low. Remember, you are not only trying to reduce WIP, you are also trying to prevent shortage of work for the bottleneck.

HOW DO WE KNOW WE DID IT RIGHT?

If you have done everything right, you will now have a constant predictable flow of results, i.e. you will have a stable throughput. You also have a higher flow efficiency

But...

Before you dive into the optimization process, consider the following.

Are all of your "work centers" really "working"? Do they add value to the outcome, or are they just quality assurance centers? Do they need to do their work exactly where they are now, or could you improve your process by moving them elsewhere? Or maybe you just need to remove them from your process?

More on late feedback in the next chapter of this series