Es war einmal ein Flight Level, Blog

Zurück

|22 Mar 2019|Klaus Leopold

Es war einmal ein Flight Level

Flight Levels

Als ich letztens so am Pool hoch über Bangkok lag und gerade 10 Minuten nichts zu tun hatte, habe ich in einem Twitter-Thread die Geschichte der Flight Levels zusammengefasst. Für mich war es eine gute Übung, um selbst zu sehen, wo ich derzeit mit meiner Idee stehe. Für euch ist dieser Rückblick vielleicht ganz hilfreich, um das Modell der Flight Levels noch besser verstehen zu können.

2011 sollte ich bei einem Kunden ca. 300 Teams Kanban beibringen. Ich zählte die verrechenbaren Tage, und vor dem Einschlafen dachte ich bereits darüber nach, welche Farbe mein neuer Porsche haben sollte. Aus Sicht des Consultants wäre es natürlich sehr lukrativ gewesen, 300 Teams zu agilisieren. Aus Sicht des Unternehmens war es jedoch kompletter Wahnsinn: Es wäre extrem viel Kohle investiert worden, die Mitarbeiter wären frustriert gewesen, und unterm Strich wäre daraus eine große Suboptimierung entstanden, die keinen Erfolg gehabt hätte. 2011 bestand meine Welt noch zu 100 Prozent aus Kanban, und nach wie vor finde ich es extrem wertvoll, Teams auf diese Art und Weise zu helfen. Doch schon damals habe ich immer versucht, Kanban – wann immer möglich – teamübergreifend einzuführen, denn eine Organisation ist mehr als die Summe ihrer Teams.

Eine Organisation ist wie eine Tastatur

Statt der Konfiguration meines Porsches entstand daher die Tastatur-Metapher: Nehmen wir an, unsere Organisation ist eine Tastatur. Jedes Team bedient eine Taste und wir müssen einen Brief schreiben. Durch schnelle Teams wird der Brief nicht schneller fertig! Vielmehr müssen wir sicherstellen, dass das richtige Team zur richtigen Zeit die richtige Taste drückt. Wenn wir nur lokal die Teams optimieren, bedeutet das noch lange nicht, dass die gesamte Organisation optimiert wird. Leider leuchtete die Tastatur-Metapher auch meinem Kunden ein. Wir haben Kanban in manchen Bereichen teamübergreifend eingeführt und ich habe immer noch keinen Porsche. Stattdessen hilft mir die Tastatur-Metapher seit 2011, Unternehmen davon zu überzeugen, die Wertschöpfung zu optimieren, und nicht die Organisationsstrukturen.

Das Problem bestimmt den Fokus

Nachdem ich zur Erkenntnis gekommen war, dass Kanban sowohl auf Teamebene als auch teamübergreifend funktioniert, versuchte ich, dieses Learning zu formalisieren. So entstanden die Flight Levels: Je nachdem wie hoch man fliegt, sieht man verschiedene Dinge. Fliegt man tief, sieht man viele Details, aber dafür nicht sehr weit. Fliegt man hoch, hat man einen Rundumblick, aber die Details gehen verloren. Der wichtige Punkt für das Verständnis der Flight Levels ist: Ob man hoch oder tief fliegt inkludiert keine Wertung. Wer schnell von Wien nach New York will, wird in einem schnellen Flugzeug ziemlich hoch fliegen. Wer die Landschaft genießen will, nimmt einen Helikopter und fliegt tief. Also: Ein „hohes“ Flight Level bedeutet nicht, dass es besser ist – es löst einfach ein anderes Problem.

Ursprünglich gab es nur zwei Flight Levels: FL1 = Team (Taste drücken) und FL2 = mehrere Teams/Wertstrom (Brief schreiben). Es stellte sich jedoch schnell heraus, dass Unternehmen nicht nur einen einzigen Brief schreiben. Also war die logische Folge FL3 = Portfolio (mehrere Briefe). Da ich 2011/2012 noch die meiste Zeit mit Teams arbeitete, unterschied ich auf FL 1 zusätzlich zwischen Teams mit koordiniertem und ohne koordiniertem Input – es gab also vier Flight Levels, und diese Unterscheidung war mir damals auch wichtig. Doch die Unterscheidung der Input-Koordination auf Teamebene ist völlig wurscht, denn sobald es ein FL2 gibt, wird der Input koordiniert. Die Strategie muss es daher sein, ein FL2 zu etablieren.

Kanban und Flight Levels trennen sich

Und plötzlich hoben die Flight Levels ab. Immer mehr Organisationen fragten nach, wie sie die Flight Levels umsetzen konnten. Das war echt super! Viele von ihnen hatten jedoch schon Scrum auf der Teamebene im Einsatz. Es war politisch nicht immer leicht, die „Kanban“ Flight Levels einzuführen – sie wurden als Konkurrenz zu Scrum gesehen. Für mich standen Scrum und die Flight Levels jedoch nie in Konkurrenz! Natürlich können Teams weiterhin scrummen. Trotzdem ist es sinnvoll, dass sich diese Teams koordinieren, wenn zwischen ihnen Abhängigkeiten bestehen. Das Gleiche gilt für Kanban-Teams oder irgendwelche Teams. Das ist genau die Aufgabe eines Flight-Level-2-Systems.

Als ich die ersten Flight-Level-2-Systeme baute, war ich noch völlig überzeugt, dass es „richtige“ Kanban-Systeme sein müssen – also Dinger mit vielen Spalten am Board, mit Serviceklassen, WIP-Limits etc. Je mehr Erfahrung ich mit FL2-Systemen sammelte, desto unwichtiger wurden diese Systemeigenschaften. Effektive Flight-Level-2-Systeme sind in der Praxis meist relativ simpel und entsprechen nicht den Anforderungen, die die Lean Kanban University (LKU) an Kanban-Systeme stellt. Es braucht aber auch nicht mehr. Auf FL3 trifft das sogar noch viel mehr zu. Mein Freund Kulawat Wongsaroj sagte letztens beim Abendessen etwas sehr Schönes: „Bei Flight Level 2 und 3 geht es nicht ums Board. Die Systeme stellen Kommunikationspunkte dar.“ Das kann ich nur unterstreichen, und man darf vor der Implementierung von Flight-Level-2-Systemen durchaus großen Respekt haben, wie diese Beispiele zeigen:

Seit ca. 2014 nenne ich die Flight Levels nur noch Flight Levels, und nicht „Kanban Flight Levels“. Wieso das? Die Flight Levels sind außerhalb der Kanban-Community wesentlich weiter verbreitet als innerhalb der Community, und sie werden auch häufiger in Nicht-Kanban-Umgebungen verwendet, um die Arbeit von verschiedensten Teams zu koordinieren – egal, welche Methode die Teams verwenden.

Strategisches und operatives Portfolio

Eine Sache will ich noch aufklären. Bis ca. 2015/16 war mit Flight Level 3 das Portfolio gemeint (alle Briefe, die wir schreiben). Heute umschreibe ich mit FL 3 das strategische Portfolio (welche Briefe sollen wir schreiben) und mit FL2 den Wertstrom (ein Brief) und das operative Portfolio (alle Briefe, die wir schreiben) – um wieder mal die Tastatur-Metapher zu bemühen. Ich will mal erklären, wie es dazu kam.

Meine ursprüngliche Idee war, dass am FL3-Board explizit gemacht wird, an welchen Initiativen gearbeitet wird, die sich natürlich an der Strategie ausrichten – so wie es Matthias Patzak in diesem Video erklärt (das es auch mit englischen Untertiteln gibt, danke Matthias!)

2015 sollte ich dann bei einer 100-Prozent-IT-Tochter einer Bank ein Flight Level 3 einführen. Es gab superviele Projekte im Portfolio und ich fragte natürlich, warum an diesen Sachen gearbeitet wurde, und damit meinte ich: Welche strategischen Aspekte sollten damit abgedeckt werden? Die Antwort war: „Wir kennen keine Strategie. Wir bekommen die Projekte von der Bank zugewiesen.“ Wir bekommen die Projekte zugewiesen – das gab mir zu denken … Aus Sicht der Bank war die IT-Tochter eine reine Kostenstelle. Die Bank hatte wahrscheinlich eine Strategie, die IT-Tochter musste aber einfach nur liefern.

Nicht denken, liefern :). Jetzt kann man sagen, das ist böse und die müssen doch und überhaupt sollen sie alle pleite gehen bla bla bla. Ich träume ja auch gerne von der optimalen Welt und natürlich kann man argumentieren, dass die beiden Unternehmen zusammengelegt werden müssten, dass mit Business gemeinsam crossfunktionale Teams gebildet werden müssten usw. Alles gut und richtig, nur hilft das meistens den Kunden nicht, wenn sie vor ganz konkreten Problemen stehen. Als kleine Randnotiz: Das ist auch ein bisschen die Schwierigkeit, die ich mit vielen agilen Weltverbesserern habe. Das ganze System muss sich ändern, und wenn sich um mich herum alles geändert hat, dann ist gut. Wir brauchen diese Visionäre, kein Thema, sie sind nur meistens keine guten Berater für konkrete Probleme.

Also, IT-Tochter der Bank, viel operatives Business, keine Strategie. Trotzdem muss die Arbeit an den vielen Initiativen koordiniert werden. Endlich wurde mir klar, dass es offensichtlich nicht nur dasPortfolio gibt – es gibt anscheinend ein operatives und ein strategisches Portfolio. Das ist auch heute noch mein letzter Stand des Irrtums.

Im operativen Portfolio geht es primär ums Koordinieren: Das richtige Team arbeitet zur richtigen Zeit an der richtigen Initiative. In meiner Denkweise wäre das ein klassisches Flight Level 2 – Koordination. Die Strategie ist uns in diesem Fall egal, wir müssen es einfach machen.

Flight Level 2 im Sinne eines operativen Portfolios sehe ich auch häufig in Agenturen. Dort gibt es einen Haufen an Kundenprojekten, die einfach gemacht werden müssen, um Geld zu verdienen. Natürlich bzw. hoffentlich arbeiten Leute auch an strategischen Themen für die Zukunft, aber die operative Arbeit überwiegt und muss einfach gemacht werden. Wenn man davon ausgeht, dass die Initiativen nicht ganz rechts auf einer Wardley-Map zu finden sind, gibt es bessere Wege als Projektpläne, um diese Arbeit zu koordinieren. Man könnte zum Beispiel auf agile Praktiken zurückgreifen und mit einem operativen Flight-Level-2-Portfolio die Teams so koordinieren, dass sie zur richtigen Zeit an den richtigen Initiativen arbeiten. Mein heutiger Stand des Irrtums ist also folgender:

Wenn es um die operative Umsetzung von Initiativen geht, ist es Flight Level 2.
Wenn es um die Strategie und die Ausrichtung der Arbeit an der Strategie geht, ist es Flight Level 3.

Erschwerend kommt hinzu, dass in der Praxis die Flight Levels selten sauber getrennt werden. FL 2 und 3 sowie FL1 und 2 werden häufig vermischt bzw. kommen auf einem Board vor. Deswegen starte ich immer mit dem Erstellen einer Flight-Level-Architektur (mir gefällt der Name nicht), um herauszufinden, welche Boards überhaupt gebaut werden müssen.

Flight Levels sind Work in Progress

Das Thema Flight Levels ist natürlich nicht „fertig“. Derzeit beschäftigt mich eine Frage, die für mich durch ein reales Fallbeispiel aufgekommen ist, das wir im Rahmen der Ausbildung zum Enterprise Kanban Coach behandelt haben. In einer großen Organisation wurde in der Testabteilung, die aus vielen Teams besteht, ein FL2-Board zur Koordination eingeführt. Ist es Flight Level 2, wenn mehrere gleiche Spezialisten-Teams (z.B. Test-Teams) ihre teamübergreifende Arbeit auf einem Board koordinieren? Puh, das riecht stark nach lokaler Optimierung, aber es sind mehrere Teams.

Flight Level 2 beschreibt eigentlich die Ende-zu-Ende-Koordination der Wertschöpfung. So weit sind aber viele Unternehmen noch nicht. Ich sehe häufig eine Ende-zu-Ende-Koordination in der Software-Entwicklung, die zum Beispiel nach Scrum aufgestellt ist. Die Wertschöpfung einer Organisation inkludiert aber meistens viel mehr als nur Software-Entwicklung. Bei meinem derzeitigen Kunden in Bangkok würde agile Software-Entwicklung sicher als lokale Optimierung gesehen werden. Wir haben letzte Woche eine Flight-Level-Architektur erstellt, und da war die Software-Entwicklung nur ein Post-it mit dem Titel „IT“ – dahinter verbergen sich ca. 1000 Leute, aber für das Business ist es viel zu wenig, nur dieses Kästchen zu agilisieren.

Und wenn er nicht gestorben ist, dann grübelt er noch heute…