„Lasst uns Flight Levels machen“ haben sie gesagt…

Gastbeitrag von | 24.06.2021 | Prozesse & Methoden |

Wie zäh das werden würde, haben sie nicht gesagt!

Klaus Leopold hat in seinen beiden Büchern „Kanban in der IT“¹ und „Kanban in der Praxis“² darüber nachgedacht, wie sich Kanban skalieren lässt und welche Elemente dafür notwendig sind. Seine Gedanken hat er in ein Modell gegossen und dieses Flight Levels genannt.

Das Flight Level Modell ist im Grunde relativ einfach aufgebaut und per se nichts Neues. Die Idee ist, die Organisation in drei Ebenen zu unterteilen, wobei es innerhalb einer Organisation unterschiedliche Granularitäten auf unterschiedlichen Ebenen gibt. Die Ebenen unterteilen sich in

  • das strategische Level,
  • die End-2-End Koordination und
  • die Operative.

Level 1, also die Operative, ist das Level, welches wir vermutlich alle am besten kennen, und mit dem wir wahrscheinlich unmittelbar oder mittelbar zu tun haben. Es ist auch das Level, was Organisationen sehr häufig optimieren wollen. Hier werden Themen bspw. nach Scrum oder Kanban umgesetzt.

Level 2 ist die Ebene der Koordination. Hier werden die Themen auseinandergenommen und geschaut, wer alles an den Themen beteiligt ist und kooperieren muss.

Auf Level 3 finden sich alle strategischen Themen und Initiativen einer Organisation.

Ziel der Flight Levels ist es, diese drei Ebenen in der Organisation ausfindig zu machen und miteinander kommunizieren zu lassen, Potentiale zu identifizieren und so Verbesserungen anzustoßen. Und so hieß es eines Tages in unserer Organisation: „Lasst uns Flight Level machen!“ Wie zäh das werden würde, war uns nicht bewusst!

Warum manches vielleicht nicht so schnell klappt

Alles fließt … (nicht)

In unserem Unternehmen sind Synchronisation und Abstimmung übliche Tätigkeiten. Wir sind darin geübt und dachten daher anfangs, das fliegt schon von alleine und alle machen mit. Gerade auf Abteilungsebene. Doch irgendwie wollte es nicht so einfach klappen. Wir hatten bspw. die Situation, dass bei einem Weekly Standup alle für die Koordination und den Informationsaustausch wichtigen Personen anwesend waren, aber die Scrum Master fehlten. Damit fehlte die Moderation und der Austausch endete bereits nach 5 Minuten. Na ja…

Abhängigkeiten & Schwierigkeiten kommunizieren

Es gibt Situationen, in denen zwei Teams voneinander abhängig sind, und ein Team mit seiner Zulieferung in Verzug gerät. Sofern alle Beteiligten miteinander sprechen und entsprechende Entscheidungen mit aller Konsequenz bewusst treffen – alles gut. Kompliziert wird es erst, wenn diese Entscheidungen einseitig getroffen und die Beteiligten beim wöchentlichen Synchronisationstermin vor vollendete Tatsachen gestellt werden. Auch wenn das nach einer relativ banalen Situation klingt, kommt sie oft in Organisationen vor. So auch bei uns. Nicht immer lassen sich Abhängigkeiten vermeiden, also haben wir gelernt, besser mit solchen Situationen umzugehen, mögliche Schwierigkeiten im Blick zu behalten, und bei Bedarf gemeinsam nach Lösungen zu suchen.

Führungsteam? Das schaffen wir auch so!

Auch wenn im agilen Umfeld häufig von dem Ziel gesprochen wird, dass sich Führungskräfte abschaffen sollen, bin ich der Meinung, dass es immer wieder Situationen gibt, in denen Führungskräfte benötigt werden. Obwohl die Führungskräfte bei uns fachlich selten bis gar nicht involviert sind und die Teams größtenteils ihre Entscheidungen selbst treffen können, hat bei uns die Vorbildfunktion der Führungskraft gefehlt. Diese Situation wurden nicht nur von den Scrum Mastern, sondern auch von den Führungskräften unterschätzt. Alleine, dass Führungskräfte bei den Meetings anwesend sind oder immer wieder auf das Flight Level Board hinweisen und somit den Rahmen festlegen, hat uns geholfen.

Was wir für unsere Arbeitsweise lernen können

Flight Levels als Tool für Stakeholdermanagement

Viele sehen die Flight Levels als ein Koordinationsinstrument. Aus meiner Sicht bietet das Modell aber mehr. Es geht darum, mit den Flight Levels aktiv zu arbeiten, und sich nicht nur in Meetings abzustimmen. Ein Beispiel ist das Managen der Stakeholder außerhalb der Regeltermine mit dem Flight Level Board. Dabei geht es darum, das Board proaktiv in Abstimmungsrunden einzubeziehen und aufzuzeigen, welche Limits es gibt und warum gewisse Themen gerade nicht umgesetzt werden können. Das Flight Level Board immer wieder als Gesprächsgrundlage einzusetzen und immer wieder zu sagen „Lass uns doch mal eben einen Blick auf das Flight Level werfen“ erspart mit Sicherheit viele Diskussionen. Genau das hat eine Product Ownerin bei uns für sich erkannt und eingesetzt.

Ausbaufähige Koordination

Das Flight Level hat bei uns gezeigt, dass wir nach wie vor unsere Koordination mit 11 Teams verbessern können und zwar nicht nur während der Umsetzung einzelner Themen. Wenn wir einen Schritt zurückgehen, also noch bevor ein Thema überhaupt auf einem Board landet oder gestartet wird, haben wir sicherlich Potential. Auch hier können wir lernen, das Flight Level Board als Planungsgrundlage zu verwenden. Was können wir aus dem Status quo ableiten? Wie können wir unsere Planungen basierend auf dem Flight Level machen? Und wie eben schon erwähnt, wie setzen wir das Flight Level proaktiv in der Kommunikation ein.

Zusammenarbeit fördern und fordern

Der zentrale Punkt, den das Flight Level in den Vordergrund schieben möchte, ist die Kommunikation zwischen den Levels und auch innerhalb der Ebenen. Mit der Kommunikation kommt automatisch der Bedarf der Zusammenarbeit. Genau dieser Bedarf ist unseren Führungskräften und auch Scrum Mastern klar geworden. So gehen wir inzwischen proaktiv auf die Teams zu, bringen sie zueinander und haken nach, ob die Kommunikation in alle Richtungen stattfindet und wo Unterstützung benötigt wird.

Passen Flight Levels denn immer?

Für die Klärung dieser Frage sind zwei Aspekte wesentlich:

Bei den Flight Levels handelt es sich um ein Modell. Es ist KEIN Framework wie bspw. SAFe. Und was ergibt sich aus dieser Erkenntnis? Es gibt keine vorgefertigten Meetings oder Artefakte, die „einfach“ genutzt werden können, wie z.B. in SAFe das Portfolio Backlog auf Portfolio Ebene oder das zentrale Artefakt des Agile Release Trains auf der Ebene der Teams.

Die Flight Levels geben lediglich vor, das drei Ebenen benötigt werden, die miteinander kommunizieren sollen. Wie dieses Miteinander funktioniert, wird nicht wirklich beschrieben. Es gibt keine Anleitung, wie bspw. 10 oder 1.000 Leute skalieren und die Ebenen am besten verbunden werden können. Genau das ist es, was den Anwendern klar sein muss: Die Flight Levels sind ein organisches Skalierungsmodell, bei dem sich die passenden Meetings und Artefakte zusammengesucht werden müssen – entweder in dem vorhandene Meetings und Artefakte übernommen oder neue kreiert werden.

Und genau das führt zum zweiten Punkt: Dadurch das es „nur“ ein Modell ist, kann Flight Levels auch als solches behandelt werden. Es bietet Orientierung und vor allem kann es abgewandelt werden – und zwar für jede Organisation passend! Deshalb sollten sich mögliche Anwender genau überlegen, was mit dem Flight Level Modell bezweckt werden soll und welche Ebenen ggf. eingebunden oder nicht eingebunden werden: 

  • Wollen wir eine Abteilung koordinieren? Dann nutzen wir doch erstmal 2 Ebenen des Flight Levels.
  • Wollen wir strategische Themen adressieren? Dann nehmen wir doch noch die dritte Ebene hinzu.
  • Wollen wir Teams skalieren und besser miteinander arbeiten lassen? Dann ist vielleicht Flight Levels nicht das Richtige.

Somit ist die Antwort auf die Frage, ob Flight Levels immer passen aus meiner Sicht ein „Ich glaube, es passt immer“. Anwender sollten sich aber über die genannten Punkte im Vorfeld Gedanken machen und mögliche Konsequenzen berücksichtigen.

Der Weg ist das Ziel

In unserer Organisation wenden wir das Flight Level Modell weiterhin an. Wir lernen dazu und optimieren unsere Zusammenarbeit. Zurückblickend würde ich zwei Aspekte etwas anders angehen:

  • Es ist sinnvoll, von Anfang an mit einem cross-funktionalen Team zu agieren, das die richtigen Ebenen adressiert. Idealerweise sollten sich nicht nur die „agilen Experten“ um das Thema Flight Levels kümmern, sondern andere Ebenen und Mitarbeitende eingebunden werden. Das erzeugt eine breite Akzeptanz, da alle Mitwirkende als Sprachrohre fungieren. So breitet sich die Idee zügig von Product Ownerin zu Product Owner, von Führungskraft zu Führungskraft aus.
  • Wenn Sie sich für Flight Levels entscheiden und somit auf organische Skalierung setzen, fangen Sie am besten klein an und erweitern Sie kontinuierlich Schritt für Schritt. Die Betonung liegt hier eindeutig auf kontinuierlich. Etwas ins Leben zu rufen, ist das eine, es am Leben zu erhalten, ist etwas ganz anderes.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Wenn Sie sich über Good Practices bei Flight Levels oder der kontinuierlichen Verbesserungen der Zusammenarbeit in Organisationen austauschen wollen, verbinden Sie sich einfach mit Tim Scheumann auf LinkedIn.

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

Tim Scheumann
Tim Scheumann

100 % – so nähert sich Tim Scheumann neuen Themen und Herausforderungen. Was sein Interesse geweckt hat, verfolgt er mit voller Überzeugung. Das gilt für Themen wie Organisations- und Produktentwicklung oder kontinuierliche Verbesserung. An agilen Herangehensweisen faszinieren ihn die Einfachheit und die universelle Anwendbarkeit. Bei seiner Arbeit schätzt er, neue Ideen und frische Konzepte zu entwickeln und dabei mit verschiedenen Menschen zusammenzuarbeiten.
Neuen Konzepten begegnet er mit Neugier, aber auch der nötigen Portion Skepsis, sodass diese nicht einfach ohne Bedacht angewendet, sondern speziell auf den geeigneten Kontext angepasst werden.

Tim Scheumann arbeitet seit 2019 bei Hermes Germany GmbH. Angefangen hat er als Scrum Master, nun ist er als Teamleader Software Development mit dem Fokus auf die Letzte Meile tätig.