Flight Levels
Eine Gemeinsamkeit praktisch aller bekannten agilen Vorgehensmodelle ist, dass sie aus Amerika kommen und auch von dort angesiedelten Zertifizierungs- und Standardisierungs-Organisationen verantwortet und weitwerentwickelt werden. Es gibt aber Ausnahmen von dieser Regel, und eine davon kommt sogar ursprünglich aus dem deutschsprachigen Raum: die Flight Levels, entwickelt von Klaus Leopold aus der österreichischen Hauptstadt Wien.
Die zugrundeliegende Idee ist zunächst einfach: es wird davon ausgegangen, dass sich alle Arten von Arbeit, die in grossen Organisatinen durchgeführt werden, einem von drei Flight Levels (Flug-Höhen) zuordnen lassen. Operative Arbeit bildet das unterste Flight Level 1, teamübergreifende Koordination (möglichst End to End) das mittlere Flight Level 2, Strategie-Entwicklung und organisationsweite Zielsetzungen finden auf dem oberen Flight Level 3 statt.
Wichtig dabei ist, dass diese drei Flughöhen nicht (!) mit Hierarchieebenen verknüpft, bestimmten Organisationseinheiten zugeordnet oder auf eine andere Art und Weise geschützt oder exklusiv gehalten sind. Stattdessen kann und soll hierarchie- und einheitsübergreifend jeder eingebunden werden können, der zu einem Thema etwas beitragen kann, unabhängig davon wo in der Organisation er fachlich oder disziplinarisch verortet ist.
Wie Vieles andere, das in der agilen Bewegung entstanden ist, ist diese Idee keine komplette Neuentwicklung, sondern findet sich in ähnlicher Form bereits an anderen Stellen, z.B. im St. Gallener Management-Modell. In der agilen Methodenwelt haben die Flight Levels aber eine spezielle Lücke finden und schliessen können: die der fehlenden Kanban-Skalierungsframeworks. Ursprünglich sind sie auch als Ergänzung des "Lehrstoffs" der Kanban University entstanden und wurden erst später eigenständig.1
Dieser initiale Kanban University-Hintergrund ist auch die Erklärung dafür, dass die mit den Flight Levels verbundenen fünf Praktiken jedem Anwender von Wissensarbeits-Kanban bekannt vorkommen dürften. Es handelt sich um:
- Die Situation visualisieren
- Fokus setzen
- Agile Interaktionen durchführen
- Veränderungen messen
- Die Strukturen und Abläufe verbessern
Alles in allem also um einen kontinuierlichen Visualisierungs- und Verbesserungsprozess der Wertschöpfung, wie er für Kanban typisch ist.
Ebenfalls erkennbar aus Kanban übernommen ist der bewusste Verzicht auf einen formellen Rahmen aus vorgegebenen Rollen, Meetings und Vorschriften, an dessen Stelle der bewusste Start mit dem bestehenden Ist-Zustand tritt, der dann nach und nach optimiert werden kann. Daraus erklärt sich dann auch die Selbstbeschreibung als blosser "Denkansatz", der in bewusstem Kontrast zu den im Vergleich formalisierteren Ansätzen wie SAFe oder Scrum steht.
Interessant ist dabei, dass es ab der Trennung von der Kanban University (ca 2020) doch zu einer stärkeren Ausdifferenzierung und Vergrösserung der Flight Levels-Idee gekommen ist. Zwar nicht durch Meetings und Rollen, aber durch Erweiterungen wie die "Flight Items" genannten Arbeitspakete, die auf "Flight Routes" durch die Flight Level systeme fliegen, deren Analyse und Design zum Gegenstand von Werkzeugen und Praktiken wie z.B. der "Work Systems Topology" wird.
Im Zusammenhang damit sind schliesslich auch für die Flight Levels die für die agilen Frameworks typischen mehrtägigen Workshops entstanden, an deren Ende man sich einen farbigen Badge in den Lebenslauf einfügen kann, etwa "Flight Levels Professional" oder "Flight Levels System Architecture". Auf den Begriff der Zertifizierung wird dabei zwar bewusst verzichtet, die Art der Nutzung in Lebensläufen und Ausschreibungen ist aber sehr vergleichbar.
Trotz dieser offensichtlichen Gewinnerzielungsabsicht (die für sich genommen auch nicht verwerflich ist) hat sich Flight Levels in weiten Teilen der agilen Community bisher den Ruf eines irgendwie anderen, noch nicht komplett kommerzialisierten Vorgehensmodells erworben, nicht zuletzt wegen seines charismatischen Gründers Klaus Leopold, der es geschafft hat sich als einer der wenigen deutschsprachigen "agilen Thought Leader" zu etablieren.
Ob man damit tatsächlich etwas anfangen kann, liegt am Ende bei den eigenen Präferenzen. Wer offene Ansätze wie Kanban mag wird auch Flight Levels mögen, wer Wert auf stützende Rahmenbedingungen legt, wird eher mit den stärker aufformulierten Frameworks glücklich werden. Und wer aus der technischen Dimension der Agilität kommt wird den Ansatz mit freundlichen Interesse betrachten, ihn aber vor allem wegen seines Prozess-Minimalismus mögen. Jeder wie er mag.
