Flight Levels is one of the newer agile concepts around, but it is on a rise in popularity since it helps you to understand and reach business agility, regardless of which situation you happen to be in right now. The first time I came in deeper contact with the concept was just before I joined improuv GmbH. One of my future, good colleagues hung a black improuv bag, with the text “ask the team”, on the doorknob at my home… all-in-all very corona conform. In the bag I found the book “Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility“, by Klaus Leopold.  The blue and quite thin book explains the concept of business agility in an impressively clear and simple way, based on a real-life use case. In short, it explains that business agility cannot be reached by great agile teams alone, but that it is an “organization sport” where business, end-to-end coordination, and various teams need to be tightly tied together. There are three organizational flight levels and we need to define and manage agile interactions between them. In the end, we get a coherent concept for how a measurable outcome can be achieved over the complete product chain, starting with a vision, via strategies, actions, implementation, and finally via the actual product.
The Flight Levels concept gave me a new and extended view of business agility. Nowadays I often find myself thinking about agile scenarios in terms of flight levels, where I earlier had less clear concepts.

The Flight levels idea is based on a Kanban-like concept, where you may start a transition from where your organization happens to be right now and evolve from there in steps, rather than via a reorganization; You make the current situation transparent, define agile interactions, create focus, measure progress and then gradually identify areas to improve and adapt. The basic concept can easily be explained via a drawing and 15 minutes, but you will be allowed to (and need to) figure out how to implement it in your situation.

For whom and where are the flight levels a good approach?

In our work for various projects and clients, we have found the flight levels model to be useful as a thought model but also useful in places you would first not assume. Whereas the flight levels can be applied as a transition method in itself we have seen it useful as a model also within other frameworks like SAFe. Below you find two examples where ideas from the Flightlevels could be used to reach better co-ordination and focus within SAFe implementations.

Use case – production quality SW, within a large SAFe organization:

A set of teams are responsible for defining, developing, testing, and deploying production quality SW solutions, for factories in a large organization. They had issues achieving reasonable lead times, had problems with focus and prioritization but also had a lack of a clear vision and strategy for the future steps.
The development was shared between some teams within a SAFe Agile Release Train, (ART) but the definition of new features, testing and deployment was handled by experts in quality management communities and by teams in the actual factories. Lack of sufficient coordination of dependencies led to delays, frustration and very long lead times.
The vision and strategy would need to be handled by a group of worldwide distributed quality managers, with the goal to initiate innovative solutions to keep the company on the edge.

How can we use the Flight levels in the setup:
On flight level three, the strategy level, the group of managers got the responsibility to define clear and common visions for the products and a corresponding strategy to reach the goal. The strategy covers the few next years but to be actionable it is broken down into measurable objectives for one year and a quarter of a year. For the quarterly and measurable goals, we can define concrete actions, in terms of e.g. items that need to be implemented. The idea is to arrange a tight feedback loop on the strategy level, that allows the organization to learn and adapt in short time steps. The measurable goal may be formulated as a testable hypothesis that can be checked in next iteration. The breakdown into actionable strategy and into concrete activities are all visualized on a virtual whiteboard, which is accessible and transparent to the whole organization. It can be linked with Jira items.

On flight level two, the end-to-end coordination level, we define an end-to-end workflow, which describes the process of a new feature, from the idea until the final deployment. In order to handle this work flow we have representatives from the distributed teams within and outside of the ART, that meet and coordinate dependencies and blockers. This led to considerably shortened lead times since the various teams have regular interactions and can share expectations, instead of sending emails and hoping for the best effort execution. The items in the backlog are also better aligned with the vision and strategy, since the features and work items are based on the quarterly objectives. These are brought into the ART program backlog for the next Program Increment. On the coordination level, we define meetings to regularly align the activities between the teams; system engineering, development, test and deployment in factories. To improve the process, we run a retrospective between the teams to discuss what could be done better in the next iteration. 
In this SAFe setup the level 2 quality management co-ordination is implemented as a Jira end to end workflow, which is running as a sub system/workflow to the SAFe Level 2 system, the ART. The teams that are part of the actual ART still perform regular PI planning together with the ART, in parallel to the coordination for the „quality management“ value stream.   

On level one, the operational level, we have scrum or Kanban teams that visualize their progress in scrum or Kanban boards. Members from the teams on level one align with other teams on the coordination level.

In this use case we make sure to visualize and make transparent the process on every level. This gives all involved parties a coherent picture of where we are heading, what we do now, and where we may have issues in the flow, that can be improved.

Use case for a SAFe Essential Agile Release Train (ART) in a Product line in Automotive area:

A new ART is set up for a product division, covering complex embedded SW/HW products in the automotive area. How can we create a coherent view of the whole process from a great vision to a product, that our customers love?

In the „SAFe Essential“ setup (i.e. a setup of a single ART, with 50 to 125 members in teams) there is no clear proposal on how to connect the product visions and strategies with the development. Here the Flight levels offer a great idea of how to visualize and achieve a clear path from the company vision to the actual implemented product. In the same way as described in the earlier use case we introduce and visualize the strategy level on a separate virtual whiteboard. It provides transparency for visions, actionable strategies, measurable objectives and actual work items for the whole organization. The work items, „Features“ in Jira, are linked and visualized on the board. In addition to the information on the whiteboard, strategic details and business cases are kept in a Jira issue type „Business epic“, which is also linked and made available on the whiteboard. The flight level 3, strategy level, generates the inputs for the ART to work on, but is also forms a means to check if new and creative ideas from the ART comply with the agreed strategy. This is very important to allow us to keep focus on the most promising opportunities (and to make sure we „stop starting and start finishing“).

The measurable outcomes can be defined as concrete business goals, e.g. „we get good feedback and a request for a quotation from a customer, via a successful demo„. It can also be defined as a test of a product hypothesis, for instance, „90% of potential customers will regard the new user interface experience as better than the current product and would be prepared to pay 10 euro more for it.“ 

Flight level two, the coordination level, is in this case formed by the SAFe ART and the corresponding end-to-end program kanban board. The agile interactions are formed by the PI planning and other SAFe ceremonies for coordination between teams.

and … for whom and where is the flight levels actually useful?

Within improuv, we see great benefits with the Flight Levels concept and use it frequently. Not only as an alternative to traditional transition frameworks but also as a think-model, that helps us to understand and optimize situations where other frameworks may be applied; SAFe, various flavors of Scrum, etc…

The concept allows an emerging and iterative transition, where we start our journey by making the flow in our current organization transparent and adapting from there, rather than via a costly and risky re-organization. This allows us to identify opportunities for improvement, where we via hypotheses and experiments can change our organization.