+43-676-330-4803ContactImprint en de


Once upon a time there was a Flight Level

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:

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…

Do you focus on the right thing?

It strikes me that it is totally important for most companies that their staff is working. “Yes, I’m working on it” is the answer you want to hear. To be honest, I would get totally worried if I heard from people all the time that they were “working on it”. Working is far too expensive! I don’t want them to work, I want them to deliver!

The idea that working is a good thing is so deeply anchored in us that we align our actions accordingly. What is usually prioritized? Right, what is to be worked on. Wouldn’t it be smarter to look at the board from back to front and prioritize what we will deliver next and not what to work on? And what do people often talk about at stand-up meetings? Right again: What did I work on yesterday and what will I work on today? Isn’t that weird? Shouldn’t we rather ask ourselves what was delivered yesterday and what will we deliver today? As a customer, I don’t care what anyone is working on.

Working costs money, delivering makes money.


–> Download #asareminder poster as PDF <–


Cross-functionality has nothing to do with team setup

Since my new book Rethinking Agile was published, readers have been posting excerpts from it many times. I have noticed that many readers are particularly interested in the topic of cross-functionality. Like the Spotify model, cross-functional teams belong to the inventory of the agile reliquary shrine: their existence is usually worshiped without reflection, but often they are nothing more than silos whose walls have been repainted. I am of the opinion: True cross-functionality does not arise from simply throwing people from different disciplines together in a team. For all those who have not yet read Rethinking Agile: Here is the section from the book that deals with it.

Cross-functionality has nothing to do with team setup
It all sounds very romantic, doesn’t it? The fact is, though, this is about enormous change. Why should the business departments simply go along with it? The demarcation between “us” and “them” is a fundamental historical problem that exists in most organizations, regardless what type of organization it is. This can be attributed to specialized splinter groups that typically organize themselves into departments. They split themselves apart from each other and the whole organization. Requests and results are usually “given over” (or tossed over) to the other departments, whose approach and requirements might be completely different than in their own department. Then the demarcation can be seen: the departments are a red flag for product development, software developers are better than software testers, the business departments see everyone else simply as suppliers, and so on.

Trying to make a company agile does not inevitably make this situation better. Cross-functional teams are great to have and an important part of the company. However, it doesn’t necessarily mean that old prejudices just disappear. Now you just have cross-functional Team A that performs better than cross-functional Team B. Instead of functional silos, there are cross-functional silos. Congratulations! If you reduce the dependencies and combine teams according to product lines, Product Y is naturally more idiotic than Product Z. And taken from the portfolio point of view, there are only complete morons sitting at the top. With “performance” bonuses, you can easily reinforce this animosity or even make it worse. In doing so, only individual parts of an organization will be optimized, but not the value creation for the customer.This competition must first be removed. As I have shown with this company, it isn’t as easy as it sounds. It is a cultural process that already starts with recruitment. The required maxim should be “don’t hire skills, hire attitude”. Sure, subject matter expertise is important, but it is much easier to acquire subject matter competence than it is to change attitudes. Cross-functional teams are in no way the Holy Grail of agility making social points of friction between the performance areas of a value stream just magically disappear—sometimes they just shift. Bringing together various schools of thought in one team is still better than focusing on individual performance or on the performance of individual specialist silos. When it’s about focusing on the customer, integrated value generation is only a small drop in a very large bucket.

Cross-functionality is a company mentality and not an organizational setup for teams. It means creating an environment where it is ok, or even desired, to perform poorly locally (whilst learning) if it helps the overall performance of the organization. It isn’t enough having everyone is pulling on the same rope—they must all pull in the same direction, too.


–> #asareminder picture as PDF download <–

TWiG Speaks Portuguese

TWiG adds another language to its portfolio: Portuguese. Many thanks to Wellington Tonquelski Ferreira and Wilhelm Meier for the translation!   

We also fixed some minor errors in the Italien version.

So don’t wait and download it from the TWiG-Page!