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


  • 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.
Pawel Brodzinski
06 Jul 2013 14:04

I like the general idea. Especially seeing more mature Kanban implementations on team / cross-team level are coherent with an analogy of getting into another flight level. I do have two comments on its implementation though.

One is on Portfolio Kanban. It is typically assumed that when an organization starts applying Kanban principles and practices on such a high organizational level it is automatically rather mature approach.

I would argue that portfolio level implementation can be an equivalent of different flight levels (I’d go that it may be as far as 1 to 4). I’ll offer a longer explanation on my blog ( very soon.

Another comment is on applying Kanban as a change management method. I believe it is orthogonal to all other levels. I’d say that within each flight level there are shallower and deeper implementations. One of good indicators of depth of a specific implementation would be whether a team uses Kanban as change management method.

Klaus Leopold
06 Jul 2013 17:22

Hi Pawel,
I see that flight levels 1-4 are often nested in each other – a multi-tier systems emerges over time. In the best case you have a portfolio level where multiple value stream levels are nested and on each value stream level you have a combination of team/department levels. So much for theory! In practice I’ve never seen such a wide implementation. What I’ve seen is a colorful mixture of different levels which I think is what you mean when you say that portfolio level can be equivalent of different flight levels.

Just to make one point clear why I did this flight level stuff: when I was called into organizations almost everybody thought Kanban is a team-level only approach. Kanban is the new Scrum or so. I wanted to make it clear that Kanban is definitely NOT a team-level approach but it can of course be used in teams. The flight level approach helped me to get the message across. So it’s not a model to judge or assess anything. It’s a pure communication tool.

Regarding flight level 5: it also feels a bit alienate to me that it is part of the model. We will see how it will evolve… 😉

Klaus Leopold
07 Jul 2013 08:32

I’ve rewritten some parts of the article due to the valueable input from Katrin Dietze and Pawel Brodzinski. Thank you so much for this!

What’s new:
(1) I rewrote parts of flight level 1 and 2. I hope it’s now clearer what point I wanted to make: coordinated input vs. non-coordinated input.
(2) I deleted flight level 5 (change). The ideas are too immature to be published…

Thanks again for the input!

11 Feb 2014 16:05

Hi Klaus, thx for the article. Really helpful and well written! You are right that each flight level requires its own specific change mgt skills, but identifying the difference in context is a great base to continue working on.
I believe you can go really far with this.
Did I interpret correctly that there exists an evolution scenario from level 1-3 (in other words that you can evolve from level 1 to 2, and from level 2 to 3), but that level 4 is a separate flight level, that might occur in parallel?

Klaus Leopold
16 Feb 2014 05:40

Hi Vincent, thanks for the positive feedback! Regarding evolution scenarios, I’ve actually seen almost everything 🙂 The way you describe is very common. However, I’ve also seen companies starting at Flight Level 4, identifying the most crucial value streams (e.g. projects) and then „descending“ down to FL3 to optimize. Usually there’s not only one flight level present in an organization but multiple more or less interdependent kanban systems.

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