Scaling Kanban
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
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.