+43-676-330-4803KontaktImpressum en de

Posts Taged Flight Levels

Auf welchem Flight Level wird was gemacht?

Was passiert auf welchem Flight Level bzw. was sollte dort passieren? Diese Frage begegnet uns immer wieder. Zum Teil liegt das wohl daran, wie wir Begriffe wie Strategie, Operationalisieren der Strategie, Ende-zu-Ende-Koordination usw. verwenden.

Es gibt nichts Schlimmeres, als durch inkonsequent genutzte und nicht definierte Begriffe für Verwirrung zu sorgen. Dieser Beitrag ist der Versuch, diese Frage für alle (auch für uns) nochmal zu klären, damit wir alle in der Kommunikation über Flight Levels einheitlich werden und bleiben.

Das Flight-Levels-Modell ist ein Denkmodell, das auf jedes Unternehmen angewendet werden kann. Es ist auf allen Ebenen mit bereits vorhandenen Methoden kompatibel und ist selbst keine weitere „Methode“. Das Flight-Levels-Modells soll dabei helfen, zu reflektieren: Wo im Unternehmen ist der richtige Hebel, an dem wir ziehen wollen, um die Business-Agilität des Unternehmens zu verbessern und es in die gewünschte Richtung am Markt zu lenken?

Flight Level 3 – Ebene der Strategie

Flight Level 3 ist der Strategie gewidmet. Hier werden Ziele definiert, die zunächst in einen größeren zeitlichen Kontext gebracht werden (z.B. die Ziele für drei Jahre oder fünf Jahre). Danach wird Fokus geschaffen (z.B. für das nächste Jahr, für die nächsten drei Monate): Worauf will sich das Unternehmen in der nächsten Iteration konzentrieren? Welche Aktionen bringen uns dem Ziel näher und wie wird der Fortschritt gemessen? Ein mögliches und beliebtes Werkzeug für diese Strategiearbeit sind OKR – Objectives and Key Results (siehe https://de.wikipedia.org/wiki/Objectives_and_Key_Results). Wie auch immer die Strategie entwickelt wird und wieviele hierarchische Ebenen es auf Flight Level 3 gibt: Letztendlich entstehen daraus „Aktionen“ (die auch Initiativen, Aktivitäten oder Projekte genannt werden), die auf Flight Level 2 Ende-zu-Ende koordiniert werden müssen.

ACHTUNG: In die Strategieplanung können und müssen natürlich auch strategische Themen aus den Levels darunter aufgenommen werden!

Diese Aktionen werden auf Flight Level 3 priorisiert und dienen als Input für Flight Level 2, wo Aktionen gestartet werden, sobald es dafür Kapazität gibt (Pull-Prinzip). Diese Priorisierung und die Auswahl der in der nächsten Iteration durchzuführenden Aktionen schafft den notwendigen Fokus, um effizient und zielgerichtet voranzukommen.

Zu jedem Strategiethema gibt es eine oder mehrere Aktionen. In regelmäßigen Abständen wird der Stand der Zielerreichung von den Beteiligten aller Flight Levels gemeinsam bewertet – so wird Transparenz für das Flight Level 2 (und in der Folge auch für Flight Level 1) geschaffen. Durch die gemeinsame Bewertung wird allen klar, welche Initiativen/Aktionen/Dinge zur Umsetzung der Strategie des Unternehmens wie beitragen. Strategisches Alignment kann so einfach sein.

Auf jedem Flight Level kann (nicht muss!) es natürlich mehrere, sogar hierarchische Boards geben – so auch auf Flight Level 3. Ein Beispiel: Wenn sich die Strategie eines IT-lastigen Unternehmens für die nächste Iteration aus Geschäftszielen der Unternehmensführung und technischen Themen der IT-Abteilung zusammensetzt, dann werden mehrere Top-Level-Strategie-Boards existieren, aus denen eine konsolidierte Sicht erzeugt werden muss. Auch diese konsolidierte Sicht ist eine strategische Sicht, die eben aus einer Zusammenschau der beiden Top-Level-Themen besteht. Bei der Entwicklung dieses abgeleiteten Strategie-Boards werden Inputs von beiden Seiten priorisiert, Abhängigkeiten berücksichtigt und der Fokus ausgearbeitet.

Flight Level 2 – Koordination der Aktionen

Flight Level 2 ist die Werkbank der Ende-zu-Ende-Koordination im Unternehmen. Diese Ebene nimmt die Aktionen und/oder Initiativen von Flight Level 3 als Backlog Items entgegen. Daraus werden die Maßnahmen oder Arbeiten abgeleitet, die in der nächsten Iteration durchgeführt werden müssen. Flight Level 2 ist eine Koordinationsebene: Das heißt, aus den Aktionen im Backlog werden große Aufgaben (z.B. Epics genannt) abgeleitet, priorisiert und den Teams (Flight Level 1) zur Umsetzung ins Backlog gestellt. Die Teams holen sich Arbeit (Pull-Prinzip), wenn sie dafür Kapazität frei haben.

Zu jeder Aktion gibt es in regelmäßigen Abständen „agile Interaktionen“ (Standup Meetings, Workshops etc.). Damit wird der Fluss der Arbeit durch das System aufrecht erhalten und wenn nötig verbessert. Durch diese Interaktionen wird außerdem der Fokus für die jeweils nächste Iteration auf Flight Level 2 geschaffen. Dadurch wird klar, was von Flight Level 1 geliefert werden sollte.

Dem Flight Level 2 und den hier stattfindenden agilen Interaktionen kommt eine zentrale Rolle bei der Koordination und Auflösung von Abhängigkeiten zwischen Teams/Produkten/Initiativen zu. Das Managen und im besten Fall sogar Auflösen dieser Abhängigkeiten ist oft der größte Hebel, um die Flussgeschwindigkeit der Arbeit im System zu verbessern. Deswegen ist uns dieses Thema auch besonders wichtig.

Auch das Arbeitssystem auf Flight Level 2 kann aus hierarchischen Boards bestehen. Wenn die Boards auf Flight Level 2 beispielsweise an Produkten ausgerichtet sind, kann es ein oder mehrere Koordinationsboards für Produktgruppen geben. Es kann auch notwendig sein, Arbeiten zwischen verschiedenen Produkten zu koordinieren, wenn mehrere Produkte für die Umsetzung eines strategischen Themas geändert werden müssen. Dadurch ergeben sich Abhängigkeiten, die gemanagt werden müssen.

Flight Level 1 – Ebene der Umsetzung

Last but not least wird auf Flight Level 1 geliefert – es ist die operative Ebene im Unternehmen. Hier sind die operativen Teams beheimatet, die Arbeiten von Flight Level 2 (Epics) entgegennehmen. Für jede Iteration konzentrieren sich die Teams auf einen bestimmten Umfang daraus (z.B. in Scrum ist es das Sprint-Ziel) und setzen diese Aufgaben um. Auf Flight Level 1 werden zum Beispiel aus Epics die User Stories geschnitten und Tasks umgesetzt, hier werden kurze Iterationen geplant und fertige Arbeit geliefert.

Für die Koordination entsendet jedes Team Vertreter zu den agilen Interaktionen des Flight Levels 2. Aber auch auf Flight Level 1 selbst kann (und wird) es ab einer gewissen Größe des Unternehmens solche Interaktionen geben – Standups sind dafür ein Beispiel. Ein anderes Beispiel wäre ein gemeinsames Architektur-Board, mit dessen Hilfe die Teams die Architektur des zu liefernden Produkts untereinander abstimmen. Ein solches Board ist aber kein Flight Level 2 Board, da es hier um Themen geht, die direkt die Lieferung der Arbeit betreffen.

Es kann – wie bei Flight Level 3 schon angemerkt – durchaus passieren, dass dabei strategische oder produktübergreifende Themen auftauchen, die nicht als rein operative Arbeit im Rahmen der normalen Tätigkeiten abgewickelt werden können. Möglicherweise sind es Themen, die einen maßgeblichen Einfluss auf die Strategie haben. In diesem Fall ist es Aufgabe von Flight Level 1, diese Themen an Flight Level 2 oder sogar 3 weiterzuspielen, damit sie in den kommenden Iterationen eingeplant werden können.

Das wichtigste Element: Kommunikation und Interaktion

Die agilen Interaktionen auf und zwischen allen Ebenen sind die taktische Komponente der Arbeit. Hier wird definiert, wie die vorhandenen Kompetenzen so um die Arbeit organisiert werden können, dass der Outcome und nicht der Output maximiert wird. „Outcome“ bedeutet, das Richtige zu machen – und das muss nicht immer super-effizient passieren. Für ein wirtschaftlich geführtes Unternehmen ist es wesentlich wichtiger, das Richtige zu liefern und dabei nicht vollkommen ausgelastet zu sein, als bei Vollauslastung das völlig Falsche zu liefern.

Das sehen wir in Organisationen am häufigsten: Der Fokus auf den Outcome fehlt. Oftmals liefern Unternehmen sehr viel (Output), haben aber das Gefühl, damit nichts zu erreichen (kein wirtschaftlich spürbarer Outcome).

Organisationen müssen lernen, ihre Kompetenzen und Kapazitäten an der Arbeit auszurichten und nicht die Arbeit an den Kompetenzen auszurichten. Denn sonst wird vielleicht vieles geliefert, aber nicht das, was Outcome im Sinne der Strategie erzeugt.

Aber das ist eine andere Geschichte und wird in einem weiteren Beitrag näher beleuchtet.

Es war einmal ein Flight Level

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…

Lean Business Agility E032: Flight Levels in Thailand

In dieser Episode spreche ich mit Kulawat Wongsaroj über Flight Levels in Thailand. Immer mehr Unternehmen verwenden Flight Levels in Thailand und es gibt gute Gründe dafür: Flight Levels sind nicht schon wieder das nächste Agile Skalierungs-Framework sondern sie bilden eine Art Klebstoff, der die verschiedenen agilen Bereiche eines Unternehmens zusammenhält.

Kulawat Wongsaroj ist Agile Coach bei 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

Podcast: Flying at Portfolio Level

Zuerst ging es um persönliche Produktivität. Dann haben alle von agilen Teams gesprochen. Und jetzt ist es an der Zeit, von Business Agility zu sprechen.

Mit Dima Moroz von Kanbanize habe ich in einem Podcast darüber gesprochen, wie man eine ganze Organisation dazu bekommt, das Richtige zur richtigen Zeit zu tun. Die Kunst besteht darin, die wirkungsvollsten Hebel zu bedienen und wenn man die ganze Organisation im Blick hat, setzt man den Hebel am besten so hoch wie möglich an. Ob tatsächlich Wert für den Kunden geliefert wird, hängt nämlich in den seltensten Fällen vom einzelnen (agilen) Team ab, sondern vom Zusammenspiel vieler Teams auf eine agile Art und Weise. Business Agility steht und fällt aber damit, ob sich jemand auf Portfolio-Ebene darüber Gedanken gemacht, wie immer gerade so viel Arbeit die Organisation gelangt, dass regelmäßig Projekte abgeschlossen werden können.