“Let’s do Flight Levels” they said….

Guest contribution by | 24.06.2021

They did not say how tough that would be!

In his two books “Kanban in IT”Âą and “Kanban in Practice”² Klaus Leopold has thought about how Kanban can be scaled and which elements are necessary for this. He has poured his thoughts into a model and called this Flight Levels.

The Flight Level Model is basically relatively simple in structure and nothing new per se. The idea is to divide the organisation into three levels, with different granularities at different levels within an organisation. The levels are divided into

    the strategic level,
  • the end-2-end coordination and
  • the operational.

Level 1, Operational, is the level we are probably all most familiar with, and probably deal with directly or indirectly. It is also the level that organisations very often want to optimise. Here, topics are implemented according to Scrum or Kanban, for example.

Level 2 is the level of coordination. Here, the topics are taken apart and it is seen who is all involved in the topics and must cooperate.

Level 3 contains all strategic topics and initiatives of an organisation.

The goal of the Flight Levels is to identify these three levels in the organisation and to let them communicate with each other, to identify potentials and thus to initiate improvements. And so, one day in our organisation, we were told, “Let’s do Flight Levels!” We didn’t realize how tough that was going to be!

Why some things may not work out so quickly

Everything flows … (not)

In our company, synchronisation and coordination are common activities. We are practised in this and therefore thought at the beginning that it would fly by itself and everyone would join in. Especially at departmental level. But somehow it didn’t work out so easily. For example, we had a situation where all the important people for coordination and information exchange were present at a weekly standup, but the Scrum Masters were missing. This meant that the moderation was missing and the exchange ended after only 5 minutes. Oh well…

Communicate dependencies & difficulties

There are situations where two teams are dependent on each other and one team falls behind with its delivery. As long as all parties involved talk to each other and consciously make the appropriate decisions with all consistency – all is well. Things only get complicated when these decisions are made unilaterally and those involved are presented with a fait accompli at the weekly synchronisation meeting. Even though this sounds like a relatively banal situation, it often happens in organisations. This is also the case here. It is not always possible to avoid dependencies, so we have learned to deal better with such situations, to keep an eye on possible difficulties, and to look for solutions together if necessary.

Management team? We can manage that too!

Even though in the agile environment there is often talk of the objective that executives should do away with themselves, I am of the opinion that there are always situations in which executives are needed. Although the leaders in our company are rarely or not at all technically involved and the teams can make their own decisions for the most part, the role model function of the leader was missing in our company. This situation was underestimated not only by the Scrum Masters but also by the executives. The mere fact that leaders are present at the meetings or always refer to the Flight Level board and thus set the framework has helped us.

What we can learn for our way of working

Flight Levels as a tool for stakeholder management

Many see Flight Levels as a coordination tool. In my view, however, the model offers more. It is about actively working with the Flight Levels, not just coordinating in meetings. One example is the management of stakeholders outside of the rule meetings with the Flight Level board. This involves proactively involving the board in coordination rounds and pointing out what limits exist and why certain topics cannot be implemented at the moment. Using the board again and again as a basis for discussion and saying “Let’s take a look at the Flight Level” saves a lot of discussion. This is exactly what one of our product owners recognised and used.

Coordination that can be expanded

The Flight Level has shown us that we can still improve our coordination with 11 teams and not only during the implementation of individual topics. If we take a step back, i.e. before a theme even lands on a board or is launched, we certainly have potential. Again, we can learn to use the Flight Level board as a basis for planning. What can we derive from the status quo? How can we do our planning based on the Flight Level? And as just mentioned, how do we use the Flight Level proactively in communication?

Encourage and challenge collaboration

The central point that the flight level wants to push to the fore is communication between the levels and also within the levels. With communication automatically comes the need for collaboration. It is precisely this need that has become clear to our managers and also Scrum Masters. So we now proactively approach the teams, bring them together and check whether communication is taking place in all directions and where support is needed.

Do Flight Levels always fit?

Two aspects are essential to clarify this question:

Flight Levels are a model. It is NOT a framework like SAFe, for example. And what follows from this insight? There are no prefabricated meetings or artefacts that can “simply” be used, such as the portfolio backlog at portfolio level in SAFe or the central artefact of the Agile Release Train at team level.

The Flight Levels only specify that three levels are needed to communicate with each other. How this communication works is not really described. There are no instructions on how, for example, 10 or 1,000 people can scale and how the levels can best be connected. This is exactly what needs to be clear to users: The Flight Levels are an organic scaling model in which the appropriate meetings and artefacts have to be found – either by adopting existing meetings and artefacts or creating new ones.

And this leads to the second point: because it is “only” a model, Flight Levels can be treated as such. It provides orientation and, most importantly, it can be modified to suit any organisation! Therefore, potential users should think carefully about what they want to achieve with the Flight Level Model and which levels, if any, will be involved or not:

  • Do we want to coordinate a department? Then let’s use 2 levels of the flight level for the time being.
  • Do we want to address strategic issues? Then let’s add the third level.
  • Do we want to scale teams and make them work better together? Then perhaps flight levels are not the right thing.

So, in my view, the answer to the question whether flight levels always fit is “I think it always fits”. However, users should think about these points in advance and consider the possible consequences.

The path is the goal

In our organisation, we continue to apply the Flight Level Model. We are learning and optimising our cooperation. Looking back, I would approach two aspects slightly differently:

  • It makes sense to operate from the beginning with a cross-functional team that addresses the right levels. Ideally, not only the “agile experts” should take care of the issue of Flight Levels, but other levels and employees should be involved. This generates broad acceptance, as all participants act as mouthpieces. In this way, the idea spreads quickly from product owner to product owner, from manager to manager.
  • If you decide to use Flight Levels and thus rely on organic scaling, it is best to start small and expand continuously step by step. The emphasis here is clearly on continuous. Bringing something into being is one thing, keeping it alive is quite another

 

Notes (partly in German):

If you want to share good practices on Flight Levels or the continuous improvement of collaboration in organisations, just connect with Tim Scheumann on LinkedIn.

[1] Kanban in der IT
[2] Kanban in der Praxis

Tim Scheumann

Tim Scheumann

100 % – this is how Tim Scheumann approaches new topics and challenges. What has aroused his interest, he pursues with full conviction. This applies to topics such as organisation and product development or continuous improvement. What fascinates him about agile approaches is their simplicity and universal applicability. In his work, he appreciates developing new ideas and fresh concepts and working together with different people.

He approaches new concepts with curiosity, but also the necessary amount of scepticism, so that they are not simply applied without thought, but are specifically adapted to the appropriate context.

Tim Scheumann has been working at Hermes Germany GmbH since 2019. He started as a Scrum Master and now works as a Team Leader Software Development with a focus on the last mile.