Flight Levels: Arbeit auf drei Ebenen koordinieren

Flight Levels ist ein Modell von Klaus Leopold, das Arbeit auf drei Ebenen sichtbar macht: die operative Arbeit der Teams, die Koordination zwischen Teams und die Steuerung des Portfolios. Es zeigt, auf welcher Ebene Lieferung stockt, und verhindert, dass Unternehmen in der Ebene optimieren, in der das Problem nicht liegt. Das Modell eignet sich für Organisationen mit mehreren Teams, die voneinander abhängen.

Viele Unternehmen haben ihre Teams agil aufgestellt und sehen trotzdem keine schnellere Lieferung. Die Ursache liegt häufig oberhalb der Teams: Mehr Vorhaben laufen gleichzeitig, als die Organisation verkraftet, Teams warten aufeinander, und niemand koordiniert, was zuerst fertig sein muss. Flight Levels gibt dieser Beobachtung eine Struktur. Dieser Beitrag erklärt die drei Ebenen, beschreibt die Einführung in fünf Schritten und liefert eine Prüfliste, mit der Entscheider beurteilen, ob das Modell zu ihrer Organisation passt.

Was sind Flight Levels?

Flight Levels sind drei Betrachtungsebenen, auf denen ein Unternehmen seine Arbeit sichtbar macht und steuert. Klaus Leopold hat das Modell aus seiner Beratungspraxis zu Kanban und Business Agility entwickelt und mit Siegfried Kaltenecker das Buch „Kanban Change Leadership“ geschrieben. Der Name stammt aus der Fliegerei: Je höher die Flughöhe, desto größer der Ausschnitt, den die Pilotin überblickt, und desto weniger Details sind erkennbar.

Auf Flight Level 1 arbeiten die Teams an ihren Aufgaben, etwa in einem Scrum-Team mit Sprint Backlog oder in einem Kanban-System mit Spalten für den Arbeitsfluss. Auf Flight Level 2 wird die Zusammenarbeit zwischen Teams sichtbar gemacht, damit ein Produkt oder eine Leistung entsteht, die mehrere Teams brauchen. Auf Flight Level 3 steuert das Unternehmen sein Portfolio: Welche Initiativen stehen an, welche Ergebnisse sollen sie bringen, und wie viele davon kann die Organisation gleichzeitig bewältigen?

Die Ebenen sind durch ein gemeinsames Prinzip verbunden. Auf jeder Ebene wird Arbeit sichtbar gemacht, die Menge der gleichzeitigen Vorhaben begrenzt und die Zusammenarbeit in festen Rhythmen besprochen. Das Prinzip stammt aus Kanban und ist hier auf die Organisation als Ganzes übertragen. Der Beitrag zu Work in Progress begrenzen beschreibt die Grundlage.

Warum reicht es nicht, nur Teams agil zu machen?

Es reicht nicht, weil die Durchlaufzeit eines Vorhabens zum größten Teil aus Wartezeit besteht, und die entsteht zwischen den Teams. Ein Team kann seine Aufgaben in wenigen Tagen erledigen, doch das Ergebnis liegt danach in der Warteschlange des nächsten Teams. Leopold beschreibt in seinem Buch „Rethinking Agile“ genau diesen Effekt: Die Verbesserung eines einzelnen Teams verkürzt die Lieferzeit des Gesamtsystems kaum, solange Abhängigkeiten, Übergaben und eine Überlast an gleichzeitigen Vorhaben bestehen.

Ein konstruiertes Beispiel zeigt die Mechanik. Ein Unternehmen führt Scrum in fünf Teams ein, die gemeinsam eine Kundenfunktion bauen. Jedes Team liefert in Zwei-Wochen-Sprints und verbessert die eigene Geschwindigkeit. Trotzdem erreicht die Funktion den Kunden erst nach fünf Monaten, weil Team B auf Zuarbeit von Team A wartet, Team C erst nach der Abnahme von Team B starten darf und die Fachabteilung acht weitere Vorhaben gleichzeitig angestoßen hat. Eine Verbesserung auf Flight Level 1 würde hier wenig bewirken. Die Hebel liegen auf Ebene 2 mit der Abstimmung der Teams und auf Ebene 3 mit der Zahl der gleichzeitigen Vorhaben. Die Mechanik dahinter erklärt der Beitrag zu Flow Metrics, und die Folgen für die Planung beschreibt der Beitrag zu Abhängigkeiten zwischen Teams.

Wie sehen die drei Ebenen im Einzelnen aus?

Die Tabelle zeigt die Logik des Modells: Jede Ebene stellt eine andere Frage und braucht andere Verantwortliche. Entscheidend ist die Verbindung. Eine Initiative von Ebene 3 muss sich in Vorhaben auf Ebene 2 übersetzen lassen, und diese in Aufgaben auf Ebene 1. Reißt die Kette, stockt die Lieferung an der Bruchstelle, ohne dass ein einzelnes Team die Ursache sieht.

Wofür taugt das Modell, und wofür nicht?

Flight Levels taugt zur Diagnose und zur Abstimmung zwischen Teams. Es sagt nichts darüber, ob ein Team Scrum, Kanban oder eine andere Methode nutzen soll, und es definiert keine Rollen. Das Modell ist ein Denkrahmen, der Unternehmen hilft, die richtige Ebene für Verbesserungen zu finden. Es funktioniert mit Scrum im Team, ebenso mit Kanban, und es lässt sich mit anderen Ansätzen kombinieren, etwa mit den Organisationsbausteinen des unFIX-Modells.

Das Modell taugt, wenn mindestens drei Bedingungen zusammentreffen: Mehrere Teams hängen voneinander ab, die Lieferzeit ist zu lang, und die Ursache ist unklar. Es taugt weniger bei einem einzelnen Team mit überschaubarem Produkt, dort genügt eine Methode auf Team-Ebene. Auch in Organisationen, in denen die Geschäftsführung kein Interesse an der Steuerung des Portfolios hat, bleibt der Effekt klein, weil Ebene 3 ohne Entscheider nicht funktioniert.

Wie führt man Flight Levels ein? Fünf Schritte

Die Einführung beginnt mit einer Bestandsaufnahme und endet mit Rhythmen, die dauerhaft laufen. Fünf Schritte ordnen das Vorgehen.

1. Wertstrom abgrenzen: Wählen Sie einen Bereich, in dem mehrere Teams an einem gemeinsamen Ergebnis arbeiten, und beschreiben Sie die Kunden und das erwartete Geschäftsergebnis.
2. Ebenen sichtbar machen: Erfassen Sie alle laufenden Vorhaben auf einer Tafel pro Ebene mit Spalten für Warten, in Arbeit und fertig. Zählen Sie, wie viele Vorhaben tatsächlich parallel laufen.
3. Engpässe finden: Messen Sie Durchlaufzeit und Wartezeit je Ebene und stellen Sie fest, wo Vorhaben am längsten liegen.
4. Gleichzeitige Arbeit begrenzen: Legen Sie auf der Ebene mit dem Engpass eine Obergrenze für gleichzeitige Vorhaben fest, und beginnen Sie neue erst, wenn alte fertig sind.
5. Rhythmen etablieren: Vereinbaren Sie je Ebene ein festes Treffen, in dem Entscheider Vorhaben auswählen, Abhängigkeiten klären und Hindernisse beseitigen.

Die Begrenzung in Schritt 4 liefert meist die größte Wirkung, und sie verlangt Mut der Geschäftsführung. Wer zehn Vorhaben auf vier reduziert, muss sechs Anliegen zurückstellen und gegenüber den Fachbereichen begründen. Die Auswahl nach Wert, zum Beispiel nach den Kosten des Wartens, macht diese Entscheidung nachvollziehbar.

Woran erkennt man, dass Flight Levels wirkt?

Das Modell wirkt, wenn die Durchlaufzeit von Vorhaben sinkt und die Zahl der gleichzeitig laufenden Vorhaben stabil bleibt. Weitere Zeichen sind weniger Eskalationen, weil Abhängigkeiten früher auf der Tafel erscheinen, und eine Geschäftsführung, die Vorhaben nach Wert statt nach Lautstärke auswählt. Messen Sie vor dem Start den Ausgangswert, damit der Effekt belegbar wird. Eine Zeitreihe aus Durchlaufzeit und Zahl paralleler Vorhaben über zwei Quartale genügt für eine erste Bewertung.

Als Gegenindikator gilt eine Tafel, die gepflegt wird, ohne dass sich Entscheidungen ändern. Dann ist Flight Levels ein Visualisierungsprojekt geblieben. Prüfen Sie in jedem Treffen, welche Entscheidung aus der Tafel folgt, und beenden Sie Rhythmen, die ohne Entscheidung auskommen.

Flight Levels mit Niehues Consulting

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen und in über 20 Ländern auf sechs Kontinenten. Als Delivery Manager, Projektmanager oder Product Owner arbeitet er an der Schnittstelle zwischen Teams und Geschäftsführung, also genau dort, wo Flight Level 2 und 3 ansetzen.

Das Vorgehen folgt dem Niehues Delivery Model mit seinen drei Phasen. Für die Koordination über mehrere Ebenen zählen drei Prüffragen: Wer entscheidet, wer liefert, wer nutzt? Welche Rollen, Entscheidungswege und Schnittstellen braucht der Betrieb? Welche Kennzahl zeigt nach 90 Tagen, dass die Lösung ankommt? Den Einstieg bildet eine kostenfreie Erstberatung von 30 Minuten, die Sie über den Kontakt vereinbaren.