Recently, as I was lying at the pool high above Bangkok with 10 minutes and nothing to do, I summarized the history of Flight Levels in a Twitter thread. For me, it was a good exercise to see where I currently stand with my ideas. For you, this review might help you understand the model of Flight Levels better.
In 2011, I should have trained approximately 300 teams at one of my customers on Kanban. I calculated out the number of billable days and, before falling asleep, I thought about what color my new Porsche was going to be. From a consultant’s viewpoint, it would naturally be very lucrative to make 300 teams agile. From the company’s viewpoint, however, it was completely insane. They would have invested a lot of money, the employees would have been frustrated, and at the end of the day a big sub-optimization would have been created, surely leading to no success. In 2011, my entire world consisted of 100 percent Kanban, and I still find it extremely valuable to help teams with this approach. Even back then though, I always tried to implement Kanban across teams whenever possible, because an organization is more than just the sum of its teams.
 

An Organization is like a Keyboard 

Instead of configuring my Porsche, I created the Keyboard Metaphor. Let’s assume our organization is a keyboard. Each team utilizes one key and we must write a letter. Faster teams will not get the letter written more quickly! More importantly, we must ensure that the right team presses the right key at the right time. If the teams are only locally optimized, this doesn’t mean that the entire organization will be optimized. Unfortunately, the Keyboard Metaphor also enlightened my customers. We implemented Kanban across teams in some departments, but I still don’t have a Porsche. Since 2011, the Keyboard Metaphor has instead helped me convince companies to optimize value creation rather than organizational structures.

 
 

The Problem Determines the Focus

After realizing that Kanban functioned at the team level as well as across teams, I worked on formalizing this idea. Thus, Flight Levels were created: Depending how high you fly, you see various things. If you fly low, you can see many details but not very far. If you are flying up high, you have a 360-degree view but the details can no longer be seen. The important point for understanding Flight Levels is: Whether you are flying up high or down low has no implied value. If you want to get from Vienna to New York quickly, you will fly in a fast airplane at a fairly high altitude. If you want to enjoy the landscape, you take a helicopter and fly closer to the ground. A “higher” Flight Level does not mean it is better – it just simply solves a different problem.
Originally, there were only two Flight Levels: FL1 = team (press the key) and FL2 = several teams/value stream (write a letter). It quickly became clear that companies are not writing just one letter. So, the logical next step was FL3 = portfolio (several letters). Since I was working mostly with teams in 2011-2012, I also differentiated FL1 based on teams with or without coordinated input. There were four Flight Levels and this distinction was important back then. However, differentiating the team level based on input coordination is completely unnecessary. As soon as there is a FL2, input will be coordinated. So, the strategy needs to be establishing FL2.
 

Kanban and Flight Levels Separate

And all of a sudden, Flight Levels took off. More and more organizations asked how they could implement Flight Levels. It was fantastic! Many of you were already using Scrum at the team level. It wasn’t always easy to implement “Kanban” Flight Levels because of internal politics – they were seen as competing with Scrum. For me, however, Scrum and Flight Levels were never in competition with one another! Of course teams could continue using Scrum. Nonetheless, it makes sense to have these teams coordinate with each other if there are dependencies between them. The same goes for Kanban teams or any kind of team. This is the exact task of a Flight Level 2 system.
When I built the first Flight Level 2 system, I was still completely convinced that it needed to be a “proper” Kanban system, i.e. a lot of columns on the board, with classes of service, WIP limits, etc. The more experience I gained with FL2 systems, the less important these system properties became. In practice, effective Flight Level 2 systems are relatively simple and do not conform to the requirements for Kanban systems as defined by the Lean Kanban University (LKU). But a FL2 system doesn’t need all that. At FL3 this is even more true. My friend, Kulawat Wongsaroj, at dinner recently stated it quite eloquently: “At Flight Level 2 and 3, it isn’t about the board. The system represents the points of communication.” This is something worth emphasizing, and you must respect a Flight Level 2 system implementation, as these examples illustrate:

• Medical Device Development, Flight Levels and Scrum
• Agility with 350+ People at OTTO
• Business Agility @Rewe Digital

Since 2014, I have been using the term Flight Levels rather than “Kanban Flight Levels”. Why? Flight Levels are significantly more widespread outside the Kanban community than within it. And they are being used more frequently in non-Kanban environments in order to coordinate the work of various teams – regardless which method is used by the teams.
 

Strategic and Operational Portfolio

There is one thing I want to clarify. Until 2015/2016, Flight Level 3 meant the portfolio (all the letter we are writing). Today, I describe FL3 as the Strategic Portfolio (what letters we should be writing) and FL2 as the value stream (one letter) as well as the Operational Portfolio (all the letters we are writing) – again referring to the Keyboard metaphor. Let me explain how it came to this.
My original idea was that the FL3 board would explicitly depict which initiatives would be worked on, aligned with the strategy naturally – just as Matthias Patzak explains in this video (now with English subtitles – thank you Matthias!)
In 2015, I was supposed to implement Flight Level 3 at a wholly-owned IT subsidiary of a bank. There were tons of projects in the portfolio and of course I asked why these things were being worked on, meaning: Which strategic aspects should be covered with these projects? The answer was: “We don’t know the strategy. The bank assigns the projects to us.” The projects are assigned to us – that got me thinking… From the bank’s viewpoint, the IT subsidiary was a pure cost center. The bank probably had a strategy, but the IT was just supposed to deliver.
Not think, deliver. 🙂 Now you might say that this is mean and this can’t be accepted and they should all go bankrupt blah blah blah. I also like to dream of a perfect world and naturally you can argue that these two companies should be merged so that cross-functional teams can be created together with business, etc. That’s all well and good, but this rarely helps the customer when they are faced with very specific problems. A little sidenote: This is also a little bit the issue I have with many Agile idealists. The entire system must change, and once everything around me has changed, then it’s good. We need these visionaries, no question. It’s just that they are not good advisors for dealing with concrete problems.
So, IT subsidiary of the bank with a lot of operations business and no strategy. Regardless, work on the many initiatives must be coordinated. It finally became clear to me that obviously there isn’t just the portfolio – there is apparently an operational and a strategic portfolio. This is still my current understanding of things.
The operational portfolio primarily deals with coordination: The right team working on the right initiative at the right time. In my way of thinking, this would be classic Flight Level 2 – coordination. In this case, the strategy makes no difference, we must simply do the work.
I often see Flight Level 2 as an operational portfolio in agencies. There are a ton of customer projects that need to be done in order to make money. Naturally, or hopefully, people are also working on strategic topics for the future, but the operational work outweighs this and must simply get completed. If you assume that initiatives are not located at the very right of a Wardley Map, there are better ways to coordinate this work than with project plans. For example, you can draw on agile practices and coordinate the teams with a Flight Level 2 operational portfolio so that they are working on the right initiative at the right time. The way I see it at the moment is:
When dealing with the operational execution of initiatives, it is Flight Level 2.
When dealing with strategy, it is Flight Level 3.
To complicate things, in practice the Flight Levels are rarely separated from one another. FL2 and 3, as well as FL1 and 2, or even FL1 and FL3 will often be intermingled and are placed on a single board. That’s why I always start by creating a Flight Level Architecture (I don’t like this name) in order to find out which boards need to be built. But Flight Level Architecture is a topic for another article in the future…

 

Flight Levels are a Work in Progress

The Flight Levels topic is, of course, not “finished”. Currently, I am occupied with a question that arose from a real-case example we dealt with during an Enterprise Kanban Coach training. In a large organization, the testing department, which was comprised of many teams, implemented a FL2 board for coordinating their work. Is it Flight Level 2 if several equally specialized teams (for example, test teams) coordinate their cross-team work on a board? Phew! It smells a lot like local optimization, but there are several teams.
Flight Level 2 actually details the end-to-end coordination of value creation. But many companies are not that far yet. I often see an end-to-end coordination in a software development area that is setup with Scrum, for example. Value creation in an organization usually includes much more than just software development, though. At my current customer in Bangkok, agile software development would certainly be seen as a local optimization. Last week, we created a Flight Level Architecture where software development was only one Post-it with the description “IT” – this Post-it represents about 1000 people, but it isn’t enough for this business to make only this little box agile.
And the pondering continues…