Flight Levels

Ein Beispiel aus der Praxis

Projekte, die mehrere Teams oder Abteilungen beschäftigen, lassen sich mit Flight Levels hervorragend abbilden. Denn eine große Gefahr bei solchen Projekt ist: Mangelnde Abstimmung und lokale Optimierung. Abteilung A oder Team X rocken Weltklasse (was natürlich schön ist für Abt. A oder Team X) und erreichen damit zwei Dinge: Nicht nur wird kein Wert geliefert, weil ja erst das gemeinsame Ergebnis aller den Wert ausmacht; auch wird der Druck auf die anderen Abteilungen/Teams größer, weil sie sich mit all dem Zeugs beschäftigen müssen, das ihnen das Rockstar-Team vor die Füße wirft. 

Dann greift ein uraltes Prinzip der Engpasstheorie: Das Ganze ist nur so schnell wie der langsamste Teil. All die Teilergebnisse von Team X bringen nichts, wenn es ein Team gibt, das noch nicht so weit ist, nicht so schnell ist, nicht hinterherkommt. Man nennt das Verhalten von Team X in der Produktion: Auf Halde produzieren. Und das große Ganze in solchen Fällen: Schlechtes Management von Abhängigkeiten.

Business Agilität ist ein Company Sport!

Wie helfen nun die Flight Levels, eingeführt von Klaus Leopold, einem Urgestein der Kanban-Welt? Das System ist so einfach wie genial: Man betrachtet die Arbeit auf drei Flughöhen.

(3) Strategisches Level, auf dem Initiativen, Portfolio und ähnliches angesiedelt sind.

(2) Koordinatives Level, auf dem die Zusammenarbeit der einzelnen operativen Teams/Abteilungen/Services betrachtet wird.

(1) Operatives Level, auf dem die Arbeit der einzelnen Teams abgebildet ist, zum Beispiel — aber nicht zwingend! — einzelne Kanban-Teams oder Scrum-Teams oder verschiedene Abteilungen.

Und wie sieht das in der Praxis aus?

Schauen wir uns das für ein Beispiel in unserer täglichen Praxis an. Wir machen Online-Projekte, und inzwischen umfasst das viele verschiedene Funktionsteams, die erst im Zusammenspiel das wertvolle Ergebnis für den Kunden realisieren, zum Beispiel:

  • ein Entwicklerteam, das die ECommerce-Plattform für den Kunden anpasst/erweitert und Anbindungen an andere System, etwa PIMs oder ERPs implementiert
  • ein Entwicklerteam, das die Content-Management-Plattform für den Kunden anpasst/erweitert und in die Systemlandschaft einbettet
  • ein Infrastrukturteam, das die Entwicklungspipelines, Cloud-Infrastruktur, Skalierung (via Cloud) und vieles mehr betreut
  • ein Performance-Marketing-Team, das strategische und operative Aspekte betreut, z.B. Online-Marketing-Optimierung on und off site, Kampagnen, Cross-Sell- und Up-Sell-Optionen uvm.

Ich bin ein großer Fan und Verfechter von crossfunktionalen Teams, aber man sieht an dieser Aufstellung schon: Ein Team, und damit meine ich ein echtes Team mit maximal 11 oder 12 Mitgliedern, keine Gruppe von 25 Personen, wäre hier wahrlich schwer zu bilden.

Man bräuchte dann jede Expertenfunktion pro Team ein Mal in Vollzeit. Es ist in vielen Fällen unrealistisch und schlicht zu teuer, eine Organisation so aufzusetzen. Wie der Begründer von Wissensarbeits-Kanban, David Anderson, sagte: Wenn Geld keine Rolle spielt, kann man das so machen. Der Ansatz von Kanban, und damit ein Herzstück der Leopoldschen Flight Levels, ist es, die Zusammenarbeit der verschiedenen Services/Teams zu optimieren, anstatt alle Services und Funktionen in einem Team abzubilden.

Das Koordinationslevel (Level 2) in Action

Nehmen wir an, wie wollen eine Funktion in der Plattform realisieren, die die Suche im Produkt-Katalog mit der Suche im CMS verheiratet, dabei zusätzlich durch eine kleine AI für den Besucher passend ausgesuchte Cross- und Upsell-Produkte anzeigt, aber natürlich nur, wenn diese vorrätig sind. Dabei sind die CMS-Plattform, die ECommerce-Plattform und die Anbindung zusätzlicher Plattformen (ERP, PIM, AI-Suche) beteiligt. Das ist nicht einfach etwas, das ein einzelnes Team umsetz. Gehen wir davon aus, dass bei uns drei Teams daran beteiligt sind.

Die drei Flight Level zeigen nun Folgendes (siehe Bild unten):

  • (3) Strategisches Level - Wir haben n Kundenprojekte. Diese Kunden haben verschiedene Prios, Kapas etc. Welche Kunden wir wie entwickeln, ist eine strategische Frage.
  • (2) Koordinatives Level - Auf dem koordinativen Level betrachten wir den Ende-zu-Ende-Prozess, der ein für den Kunden wertvolles “Ding” fertigstellt, das manauf dem Markt verwenden kann. Ich habe bei vielen verschiedenen Kunden schon so viel Zeit darauf verwendet, zu diskutieren, ob wir diese Dinger “Features”, “Epics”, “Capabilities” oder sonstwie nennen, dass ich hier einfach nur sprechen will von: “Eher großen wertvollen Dingen”. Man sieht, dass von diesen “Dingern” gemäß Kapazitätsallokation verschieden viele pro Kundenprojekt in progress sind. Dazu unten noch ein Mini-Nachwort.
  • (1) Operatives Level - Von den in progress befindlichen “Dingern” leiten sich für die einzelnen operativen Teams kleine Arbeitspakete ab, die in den lokalen Boards (oder was auch immer) verwaltet werden. Wenn man auf das Bild klickt, sieht man das in der Vergrößerung besser. Auch hier ist mir in diesem Zusammenhang wieder egal, ob diese Level-1-Arbeitspakete nun “User Stories” sind oder “Tasks” oder “kleine Klöpse” oder “ToDos”. Nicht jedes Team wohlgemerkt hat zwangsläufig Aufgaben aus jedem Level-2-Ding.

Der Level-2-Standup

Ein wichtiger Mechanismus ist nun ein regelmäßiges Koordinieren auf Level 2. Die meisten Teams nennen das einfach Level-2-Standup. Er findet z.B. 1x pro Woche statt und man fokussiert auf den Flow, also den ungestörten Fluss der Arbeitsergebnisse. Hätten wir ein “Ding” im Status Blocked, müssten wir uns darauf konzentrieren: Woran liegts, wer kann helfen, was kann man tun? Deshalb sollten beim Level-2-Standup neben Entsandten der operativen Teams auch Stakeholder dabei sein, die die Macht haben, die Teams zu unterstützen und Lösungen herbeizuführen oder abzusegnen, wie z.B. Kapa-Umschichtungen, Umpriorisierungen, Eskalationen usw. 

Gleichzeitig hilft die Level-2-Koordination dabei, dass allen klar ist: Welches Team muss wann was machen, damit ein anderes Team nicht in einen Blocker läuft. Wenn die Schnittstelle zum PIM noch nicht funktioniert, ist es schwierig, AI-Algorithmen über das Sortiment laufen zu lassen. Es geht um ein laufendes Abhängigkeitsmanagement, weil wir alle aus der Realität wissen: Ein vorab Managen aller Abhängigkeiten, Probleme und Unwägbarkeiten ist schlicht unmöglich.

Flight Levels bringen Transparenz und Alignement

Diese Form, das große Ganze, den Scope, zu betrachten, zu gliedern und zu besprechen, dieser sog. Flight-Level-Ansatz, sorgt für Transparenz und Alignement über alle Projekt-relevanten Teams hinweg. Es ermöglicht durch den Fokus auf Koordination ein agiles Reagieren auf Veränderungen jeglicher Natur. Egal, nach welchen Regeln, Frameworks oder Ansätzen man arbeitet, sind sie eine sinnvolle Ergänzung, um globale Optimierung anzustreben.

Mini-Nachwort zum Limitieren von Work In Progress (WIP)

Ohne jetzt auf Details eingehen zu wollen: Das limitieren des “Work in Progress”, also der gleichzeitig in Arbeit befindlichen Arbeitspakete, ist ein zentraler Ansatz von Kanban. Und egal, ob man Kanban macht oder nicht: Sich auf wenige Dinge konzentrieren hat so viele Vorteile, dass ich gar nicht weiß, wo ich anfangen sollte. Also will ich hier erst mal nur sagen: Wichtig ist, auf welcher Ebene man diese Limits ansetzt. Setzt man WIP-Limits auf operativer Ebene, heißt das, die Teams sind vor Überlastung geschützt und werden zuverlässig und vorhersagbar in ihrem Output. Die Time to Market der großen, werthaltigen Deliverables (hier: die “Dinger”) wird aber nicht besser. WIP-Limits müssen möglichst weit oben in der Flight-Level-Architektur ansetzen, damit sie wirklich wirkungsvoll sind.