Scaling Kanban

System User

Scaling Agile is currently a very hot topic indeed. “Unfortunately,” in the Kanban world we can’t really jump on this topic and paint some beautiful posters with principles and pillars and recipes that explain how Kanban probably can be best scaled. Scalability is an inherent part of Kanban and therefore one cannot not scale Kanban. Scaling in a Kanban context means: Doing more Kanban. This can be done in two directions: in depth and in breadth.

Depth scaling

I understand depth scaling as extending a Kanban system in its implementation depth to improve it. You start initially with shallow Kanban and deepen it successively. This may include the introduction of better risk management, metrics or forecasting, which can provide more detailed information about the workflow. What I do, I do more intensely, more deeply in depth scaling.

Breadth scaling

Breadth scaling means adding upstream and downstream areas to the system. One basically adds more value creation. Let’s assume the development department of a company is already working with Kanban. Eventually they come to the conclusion that development and integration are actually closely related and benefits can be gained, if these two steps are better coordinated. The Kanban system is scaled in breath with the step “integrate”.

After some time, we now come to the conclusion that more intensive coordination with the business analysts or product owners could make the development much easier in terms of due date performance and faster lead times. So Kanban is once again scaled in breadth with the steps “analyze” and “roll out”, as shown in the following figure.

If there were only this one value stream within the company, all the value-adding steps in a Kanban system would now be integrated. If there are multiple value streams, scaling can of course be further thought through and, for example, look like the following figure.

In breadth scaling one extends Kanban via the value stream and finds ways to effectively coordinate the people, departments of teams involved. It is a service-oriented architecture that this procedure creates.

Value creation vs. team optimization

Generally, it is wise to free oneself from the term “team” in Kanban. There may be teams from an internal perspective of the company, but relevant for improvement is the customer’s perspective: He is interested in the result. Amazon is a simple example: The customer wants a book. If you now think about how you get the book to the customer, you will not think in teams. Rather, you will orient yourself on the path the book takes from ordering, through warehousing to delivery. In a second step, you consider how you can organize your business in such a way so that this value flow is optimal.
So if it comes to scaling Kanban, the first question is always: How do we improve value creation for the customer? Only in second place comes the question: Whom do we need to do so?

Please note that I do not say that optimization on a team level is not important! If you’re doing a birthday cake and you start by sticking the candles into the eggs, it’s probably the wrong sequence. If you start your organizational improvement journey on team level but you don’t have any idea about the problems with your value creation chain, chances are very high that you’re sticking candles into eggs.

So you see: Scaling in Kanban means nothing more than to do more Kanban. The starting point determines the path. Welcome to the world of evolutionary improvement! Welcome to Kanban land!

Loading comments

This conversation lacks your voice:
Your E-Mail Address will not be published.