+43-676-330-4803ContactImprint en de

Posts Taged Flight Levels

What gets done at which Flight Level?

What gets done at which Flight Level and what should be happening at that flight level? We encounter this question over and over. This is partly due to how we use terms like “strategy”, “strategy operationalization”, end-to-end coordination, etc.

There is nothing worse than creating confusion by using inconsistent and undefined terms. This article will answer this question again for everyone (including us), so that we will remain uniform in our communication about flight levels.

The Flight Levels Model is a way of thinking that can be applied to any company. It is compatible at all levels with existing methods and is not itself another “method”. The Flight Levels Model is a tool for reflection. What can we leverage within the company in order to improve our business agility and achieve the desired direction in the market?

Flight Level 3 is dedicated to strategy. Here, objectives are defined and are put into a larger temporal context (e.g. three-year or five-year goals). Then, the focus is placed on the next year, the next three months, or some short-term timeframe. What does the company want to concentrate on in the next iteration? Which actions bring us closer to our goal and how will progress be measured? One popular tool for this strategy work is OKR – Objectives and Key Results (see https://de.wikipedia.org/wiki/Objectives_and_Key_Results). Regardless how the strategy is developed and how many hierarchical levels are at Flight Level 3, eventually “actions” (also known as initiatives, activities or projects) are created that will need to be coordinated end-to-end at Flight Level 2. ATTENTION: Strategic topics from the levels below can and must be included in the strategic planning!

These actions are prioritized at Flight Level 3 and serve as input for Flight Level 2, where actions are started as soon as capacity is available (pull principle). This prioritization and the selection of actions to be executed in the next iteration creates the focus required to move forward efficiently and purposefully.

Each strategy topic has one or more actions. At regular intervals, the goal status is jointly evaluated by participants of all Flight Levels, which creates transparency for Flight Level 2 (and subsequently also for Flight Level 1). The joint evaluation shows how the initiatives/actions/things contribute to the company’s strategy. Strategic alignment can be so simple.

At each Flight Level there can (but not necessarily!) be several, possibly even hierarchical, boards – even at Flight Level 3. An example: The strategy of an IT-heavy company for the next iteration includes management’s business goals and the IT department’s technical initiatives. Several top-level strategy boards will exist, but a consolidated view must be generated. This consolidated view is also a strategic view with a synopsis of the two top-level topics. When developing this derived strategy board, inputs from both sides are prioritized, dependencies taken into account and the focus of the project is defined.

Flight Level 2 is the workbench of end-to-end coordination in the company. The initiatives from Flight Level 3 become the backlog items for Flight Level 2. The work or initiatives to be carried out in the next iteration are derived from this backlog. Flight Level 2 is a coordination level. Large tasks (sometimes called Epics) taken from the backlog are prioritized and placed in the implementation backlog for the teams (Flight Level 1). The teams take work (pull principle) when they have capacity available.

Each action is accompanied by “agile interactions” at regular intervals (stand-up meetings, workshops, etc.). By doing this, the flow of work through the system is maintained and improved, if necessary. These interactions also establish the area of focus for the next iteration at Flight Level 2, making it clear what Flight Level 1 should be delivering.

Flight Level 2, and the agile interactions taking place here, play a central role in the coordination and resolution of dependencies between teams/products/initiatives. Managing, and in the best case even resolving, these dependencies is often the biggest lever to improve the flow of work in the system. That’s why this topic is so important to us.

The working system at Flight Level 2 can also consist of hierarchical boards. If the boards at Flight Level 2 are oriented towards products, for example, there can be one or more coordination boards for product groups. It may also be necessary to coordinate work between different products when multiple products need to be changed for the implementation of a strategic theme. This results in dependencies that need to be managed.

Last but not least, Flight Level 1 creates the deliverables – it is the operational level in the company. This is where the operational teams who receive work from Flight Level 2 (Epics) are based. For each iteration, the teams concentrate on a certain scope (e.g. in Scrum it is the sprint target) and implement these tasks. On Flight Level 1, for example, the user stories from Epics are cut into tasks and implemented. Short iterations are planned and the finished work is delivered.

For the coordination, each team sends representatives to the agile interactions of Flight Level 2. But even at Flight Level 1 itself, there can (and will) be such interactions from a certain size of the company. Standups are an example of this. Another example would be a common architecture board, with whose help the teams coordinate the architecture of the product to be delivered. However, such a board is not a Flight Level 2 board, as it deals with topics that directly affect the delivery of the work.

As already mentioned in Flight Level 3, strategic or cross-product topics might arise which cannot be handled as purely operational work within the scope of normal activities. There might be topics that have a significant influence on the strategy. In this case, it is up to Flight Level 1 to pass these topics on to Flight Level 2 or even 3 so that they can be planned in the coming iterations.

The agile interactions at and between all levels are the tactical component of the work. Here, the existing competences can be organized around the work in such a way that the outcome, rather than the output, is maximized. “Outcome” means doing the right thing – and that doesn’t always have to happen super-efficiently. For an economically managed company, it is much more important to deliver the right thing and not be fully loaded than to deliver the completely wrong thing at full capacity.

This is what we see most often in organizations: the focus must be on the outcome. Companies often deliver a great deal (output), but have the feeling that they cannot achieve anything (no economically noticeable outcome).

Organizations must learn to align their competencies and capacities with the work, and not to align the work with the competencies. Otherwise, a lot may be delivered, but not what results in the sense of the strategy. But that is a different story and will be examined in more detail in another article.

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…

Lean Business Agility E032: Flight Levels in Thailand

In this episode I talk to Kulawat Wongsaroj about Flight Levels in Thailand. More and more organizations are adopting Flight Levels in Thailand and there are good reasons for it: Flight Levels is not yet another agile scaling framework but it rather acts as a kind of glue that holds the various agile areas together in a company.

Kulawat Wongsaroj is an Agile Coach with Lean In Consulting, Bangkok, Thailand.


Lean Business Agility Video BlogAbonniert den YouTube Kanal von Lean Business Agility oder den Podcast bei iTunes oder Overcast oder holt euch den RSS Feed.

Lean Business Agility Youtube ChannelLean Business Agility iTunes PodcastLean Business Agility Overcast PodcastLean Business Agility RSS Feed

Lean Business Agility E026: Medical Device Development, Flight Levels and Scrum

In this episode I talk to Thomas van der Burg about the development and application of custom-built test methods and equipment for medical devices in a Pharmaceutical Company. Thomas reports how the department has managed to dramatically reduce the lead time on their now almost five-year journey to an agile way of working. They achieved this by using Kanban on higher Flight Levels in addition to local team optimization through Scrum. This makes sure that the right teams are working on the most valuable product at the right time. This improvement supports that medical devices can be brought to market much earlier.

Thomas is a department leader in a global pharmaceutical company. He and his team work as Expert Service Provider in the medical device field. Thomas uses agile Hardware Development as well as agile Portfolio Management using Kanban for several years. He has also experience in agile Leadership and leading Change in Agile Transformations – in a conservative and highly regulated environment. He blogs on empowering.team

Lean Business Agility Video BlogSubscribe to the YouTube channel of Lean Business Agility or the Podcast on iTunes or Overcast or to the RSS Feed.

Lean Business Agility Youtube ChannelLean Business Agility iTunes PodcastLean Business Agility Overcast PodcastLean Business Agility RSS Feed