Kanban and its flight levels, Blog

back

|06 Jul 2013|Klaus Leopold

Kanban and its flight levels

Before you start with Kanban it is important to decide where you want to embed it in the overall organizational context. Sounds like an easy question, however, I learned that it is not always so easy to answer – especially in bigger organizations. Therefore, I developed the Kanban flight levels model which helps me to communicate the different fields of application of Kanban.

At this year’s Kanban Leadership Retreat in Austria, a group around David Anderson worked on a similar topic. They called it “mapping the Kanban universe”. Unfortunately, I could not attend this session as I was busy doing my own session on “Assessing Kanban, change, and leadership” together with Sigi Kaltenecker. Nevertheless, I’d like to share my thoughts on this topic and we will see how to proceed with it.

This article aims to give you an overview of the different Kanban flight levels in organizations. In later articles I might dig deeper into the different levels because I observed some patterns in how different organizations are using Kanban at a certain flight level. But let’s start with a high-level overview of the model…

Flight level 1: organizational unit, uncoordinated input

At this flight level Kanban is applied on an organizational unit like, a team or department. Running Kanban at this flight level is often characterized by highly specialized persons that are working together in a special department or team. I see a lot of clients especially in high tech environments like the aviation, railway or automotive industry working in such an environment. People are often working on a very specific part of a huge system like a particular engine injection system of a passenger car or a subsystem of a weather radar device in an airliner, etc. Another example for an organizational unit on flight level 1 could be cross-functional teams where, e.g., designers, developers, and testers are working on a small product or on a subsystem of a bigger system.

Characteristic of flight level 1 is that work is thrown over the fence. There’s no coordinated queue replenishment where the input to the system is regulated. However, there are often good reasons for this: Due to a high degree of specialization these organizational units often have numerous stakeholders that require their service. I know an example where a department composed of 9 persons serves more than 100 projects. Bringing 100 project representatives to one board and let them decide which items the department has to work on next, sounds like science fiction. The consequence is that Kanban at this flight level usually suffers from a lot of expedite work which is caused by permanent re-prioritization.
No doubt, Kanban improves efficiency of the department. However, the point is that there’s NO input coordination and therefore, people are often working on the “wrong things” more efficiently which does not significantly increase the overall efficiency.

Flight level 2: organizational unit, coordinated input

Flight level 2, is defined by the same organizational units as on flight level 1. However, there’s one crucial distinction: Flight level 2 is characterized by coordinated input! A typical example would be an organizational unit which receives work through a queue replenishment meeting. Doing a queue replenishment provokes essential learning: the organizational unit is not a black hole where stakeholders can pour in an infinite amount of work. No, you learn that there is something like demand on the one hand – all the great ideas we have – and capability on the other hand – the ability of the organizational unit to finish work. Having a coordinated input in place means balancing demand vs. capability. As a consequence, the amount of re-prioritization is significantly reduced because people are doing the right things more efficiently; “the right thing” from the viewpoint of the stakeholders.

To roughly wrap up the first two flight levels, we can see that the improvement target is departments or teams. As illustrated in the following figure, they are only part of an overlying value stream:

The illustration shows a hypothetical value stream which I’ve seen in different variants in project businesses. One can see that design, development, and test are only part of the overall value stream. You will agree that most of the time there’s no value for the customers if you only deliver tested code. You will also have to integrate your code in a bigger (live) system, put it into operation, train users, etc. On the other hand, customers usually don’t fall out of the sky with a crystal clear specification in their hand so that you can start realizing the idea immediately. No, there’s a lot of work to do before you can start coding: generating leads, understanding what the customer wants, contracting, setting-up the project team, etc… Please note that this is a generalized example of doing projects. If you’re in another business like, for instance, you are maintaining a product or you are working in IT-ops your value stream will look different of course. However, the idea is the same: Creating value for the customer needs much more than a hyper productive team! This is exactly where the next Kanban flight level starts:

Flight level 3: value stream

Russell Ackoff would probably phrase it like this: At flight level 3 organizations understand that “the performance of a system is not the sum of its parts but the product of its interactions” (see e.g. this video). The improvement target at this flight level is not individual teams or departments but parts of the value stream where multiple organizational units (teams, departments, etc.) are needed in order to generate value for the client. In the best case you are focusing on the overall value stream.

If I got David Anderson right, he would call this flight level “service oriented Kanban”. The idea is that one organizational unit is providing a service for another organizational unit. So far so good; that’s what a lot of companies think they are doing. However, the crucial point is that the service has to be provided in a coordinated way, i.e., work is NOT thrown over the fence! You are NOT directly optimizing individual organizational units but their interactions! Operating Kanban at this flight level leads to a tremendous performance increase, mostly because (1) queue size and wait time is reduced significantly and (2) people are working on the right things, because there is a coordinated input to the system. If you ever experienced organizations that are operating at this flight level you can only smile if someone wants to sell success through high-performing teams…

Flight level 4: portfolio

Usually organizations are not working on one single project. I often ask senior managers: “With what are you creating value for your customers?” As simple as the question might sound, the answer is not always straight forward. Try it yourself! Organizations are usually working on a mix of projects, products, configurations, changes, systems, etc. The implication is that there are multiple value streams in an organization. And that’s exactly where the portfolio flight level starts: manage multiple value streams with Kanban. A rough sketch of Kanban at this flight level might look like the following:

In this example, Kanban is used to manage three projects and two products. One can see that the value streams for projects and products are different. The work item type on this flight level is usually a rather big functionality like e.g. “Chinese version of product XYZ” or “integrate Bayesian network with recommender system”, etc. David Anderson would call this sagas 🙂 The big benefit of doing Kanban on this flight level is that big functionalities are in competition which means that organizations have to make a conscious decision what they want to get finished next. You really have to balance demand vs. capability. Or in other words, you are getting closer to reality by uncovering statements like “we have to finish all this stuff until October” as nonsense. You will really learn what it means to make risk decisions on what to finish next instead of working on everything at once which means nothing gets finished at all.

Just a short note on the side: Work items on this flight level are usually broken down into smaller bits (like e.g. epics, user stories, or requirements) which are then flowing across flight level 3 or flight level 1 and 2 kanban systems.

Flight levels and change

It’s important to note that the different flight levels do not describe steps you have to get through! You can start on any flight level you want. However, introducing Kanban on each flight level requires different change management skills. I will come back to this in a later article.

Summary

Kanban flight levels is a model which defines possible scopes of Kanban. I know that reality is much more colorful than this model. However, we also know that all models are inherently wrong; some are useful 😉
I use the model to (1) show the potential of Kanban and to (2) clarify with my client where we want to start the Kanban change initiative.
Flight level 1 focuses on improving an organizational unit like teams or departments. Main characteristic on this flight level is, there is no coordinated input – no queue replenishment meeting. There’s the danger that people are processing the wrong things more efficiently which does not significantly increase the overall efficiency.
Flight level 2 also focuses on improving individual organizational units. However, at this flight level the input to the organizational units is coordinated. This leads to a great performance increase because the work being processed is “more right”.
Flight level 3 focuses on improving the value stream by optimizing the interactions of organizational units which leads to a tremendous performance increase, mostly because (1) queue size is reduced significantly and (2) people are working on the right things.
Flight level 4 focuses on improving multiple value streams which leads to a much better understanding of balancing demand vs. capability and managing risk.
Each flight level requires a different change approach to successfully start with Kanban.

—

Thanks to Katrin Dietze and Pawel Brodzinski for their valuable input on the first article and thanks to Sigi Kaltenecker for reviewing the original article.