Mit Flight Levels zum Fliegen kommen – Erfahrungsbericht

Teamübergreifende Abstimmungen und Konflikte lösen, sich auf das Liefern von Ergebnissen konzentrieren und dafür die Arbeit richtig managen. Herausforderungen, denen auch die IT unseres Großkunden ausgesetzt ist. Dieser Blogbeitrag erzählt, wie Fabian Biebl, Daniel Westermayr und Bastian Kröckel dies in einem Individualtraining angegangen sind und wie Flight Levels den Kunden zum Fliegen bringen können.

Die Vorgeschichte

Um möglichst viel Effizienz in der Erstellung und Pflege der Kundensysteme sicherzustellen, wurden vor Jahren drei IT-Teams so geschnitten, dass ähnliche Skills gebündelt werden. Es entstanden ein Fachteam, ein Middleware-Team und ein Development-Team. Wie man inzwischen gelernt hat, bringt dieser Schnitt nach Komponenten eine Silo-Problematik mit sich, die es erschwert, gemeinsam an übergreifenden Ergebnissen zu arbeiten. Aufgrund der Vielzahl an zu betreuenden Systemen und eingesetzten Technologien sind selbst in den drei Teams die Aufgaben so unterschiedlich, dass die Teams zwar eine Klammer über die Skills bieten, aber intern eigentlich Ein-Personen-Teams sind.

Der Wunsch ist nun, sich mehr auf das Fertigwerden der inhaltlichen Arbeiten konzentrieren zu können und die Konflikte, die aus der starken Fragmentierung der Aufgaben und Personen entstehen, abzubauen. Während die Teams grob wissen, was ihre Arbeitslast ist, gibt es teamübergreifend diese Transparenz nicht. 

Die agile Analyse

Im agilen Sinne gilt es also, Flow sicherzustellen und Value zu erzielen. Dabei bedarf es Transparenz über die Arbeitslast und die Workflows. Man wird ablassen müssen von einer personenbezogenen Ressourcenplanung für 100% Auslastung, um flexibler und zielgerichteter agieren zu können. Das Stichwort hier ist Slacktime. Auch gilt es, die Anzahl an gleichzeitiger Arbeit mit WIP-Limits zu reduzieren, um dafür mehr Outcome zu erzeugen.

Da viele lokale Optimierungen vorherrschen und globale Optimierungen sich nicht per Bauchgefühl bewerten lassen, ist es unabdingbar, zu messen und mittels passender KPI einen objektiven Regelkreis zu erstellen. 

So weit die nüchterne Analyse systemisch geschulter Coaches und bereits ein großer Teil der Themen, die im Training bearbeitet werden müssen. Doch ist das schon alles?

Die Organisation muss mitlernen

In jeder Organisation sind die Menschen stolz auf ihre Arbeit. In einem gegebenen Rahmen gestalten sie sich ihre Arbeitsabläufe über Jahre hinweg und viele Regeln dafür sind nie aufgeschrieben, sondern sind zur gelebten Realität, zur Organisationskultur geworden. So etwas ändert sich nicht über Nacht und schon gar nicht darüber, dass Coaches plötzlich die lieb gewonnenen Arbeitsabläufe konfliktträchtig als nicht mehr funktional titulieren. Das agile Répertoire muss noch ein wenig in den Werkzeugkästen des Coaches warten.

Stattdessen bedarf es zu Beginn eines Problembewusstseins:

• Was wollen wir erreichen und wie stellen wir objektiv fest, ob wir uns dem nähern? 
• Welches aktuelle Verhalten führt denn zu diesem Problem? 
• Was ist denn gut und soll beibehalten werden?

Und selbst das wird noch nicht reichen, um einen Impuls zu setzen, der Dinge in Bewegung bringt. Die Führungsmannschaft muss dieses Problem klar benennen und ein glaubhaftes Mandat dafür geben, dass Veränderung erwünscht ist und die Mitarbeitenden dabei mitgestalten sollen. Das ist in einer Organisationskultur, die wenig darauf ausgerichtet ist, eigenverantwortlich zu handeln, schwierig und lässt sich nicht über Nacht erreichen.

Diese Grundvoraussetzung herzustellen war ein maßgeblicher Faktor bei der Gestaltung des Trainings und hat auch den Unterschied zwischen reiner Wissensvermittlung und einem echten Momentum für Veränderung dargestellt.

Die Agenda des Trainings

Für das Training wurden die Product Owner, das Middleware-Team und die beteiligten Manager eingeladen. Für das Development-Team wurde bereits vor einigen Monaten ein ähnliches Training durchgeführt.

All unsere Trainings zeichnet ein hohes Maß an Interaktivität und der weitgehende Verzicht auf Folien und Frontalbeschallung aus. In diesem Fall handelt es sich auch um ein für diesen Kontext einmalig konzipiertes Training, welches teilweise Workshopcharakter hat. Dies ist sinnvoll, da keine Zertifikate nötig sind und es sich um interne Teams handelt, die sich kennen und für sich Lösungen finden wollen. Das ist im Vergleich zu offiziellen Trainings mit Teilnehmenden aus unterschiedlichen Firmen ein großer Vorteil.

Die maßgeblichen Punkte des Trainings sind wie folgt (Ankommen, Bonding, Pausen etc. sind der Einfachheit halber hier nicht aufgeführt):

1. Warum agil?
2. Was bedeutet “Fertig”?
3. Was bedeutet “Value”?
4. Wie kann agiles Arbeiten methodisch aussehen (zum Beispiel mit Scrum)?
5. Welche Probleme sollen gelöst werden?
6. Wie funktioniert Zusammenarbeit und wie lassen sich diese Probleme sichtbar machen?
7. Wie lässt sich die nötige Transparenz und damit auch die Regeln für die Zusammenarbeit und Interaktionen herstellen?
8. Welche Rahmenbedingungen für Veränderung gibt es und wo stehen wir?
9. Welche nächsten Schritte und Randbedingungen gibt es?

Wie wir einige dieser Punkte interaktiv und attraktiv mit unseren Teilnehmenden durchgeführt haben, erfahrt ihr im weiteren Verlauf dieses Beitrages.

Warum agil?

Mit den Teilnehmenden haben wir intensiv besprochen, was ihre Produkte und Kunden sein könnten. Dabei stellte sich heraus, dass es noch keinen passenden Produktschnitt gibt, da die technischen Komponenten, die von Einzelpersonen betreut werden, zu klein und die gesamte IT-Landschaft als Ganzes zu grob ist. In der Zeit nach dem Training wird der passende Produktschnitt gefunden werden müssen. Die Anforderung dabei ist, dass dieser Schnitt nach Kundenwert erfolgen muss, nicht nach technischen Systemen.

Diese Frage ist elementar, denn sie bedingt später auch, wie Teams besser geschnitten werden können und welche Arbeit durch unser Arbeitssystem fließt. Zu benennen, dass es noch nicht für ein agiles Arbeiten passt, wirkte befreiend und zugleich herausfordernd für die Teilnehmenden.

Was bedeutet “fertig”?

In der nach Silos optimierten Arbeitswelt ist es schwierig, etwas fertig zu bekommen. Wann ist denn etwas fertig? Dann, wenn es meine Hände verlässt? In dieser Übung haben wir mit einer Definition of Done (gelb) besprochen, welche übergreifenden Arbeitsschritte bei typischer Softwareentwicklung durchlaufen werden. Hier sind viele Personen und Teams beteiligt, denn von Marketing bis Test und Montage von Technik sind im realen Leben auch außerhalb der IT viele Abteilungen beteiligt.

In unserem kleinen Beispiel wurde den Teilnehmenden schnell klar, dass etwas erst dann fertig ist, wenn es ganz rechts angekommen ist. Die zu erledigenden Tätigkeiten (blau) sind zwar auf der linken Seite höher, doch die aufkommenden Probleme (rot) nehmen nach rechts zu. Auf der Zeitachse bedeutet dies, dass Risiken möglichst früh behandelt werden sollten, denn sonst kommt es später bei der Integration zu einem Crash.

Die wichtigen Erkenntnisse sind hier gewesen, dass nur übergreifend Wert geschaffen wird und alle Beteiligten gemeinsam diesen herstellen. Etwas aus der Hand zu geben heißt noch nicht, dass es fertig ist!

Was bedeutet “Value”?

Wir haben uns dieser Frage mit einer kleinen Simulation genähert: Schreibt 5 Namen auf Kärtchen! In Variante 1 dürfen die 5 Kunden, deren Name aufgeschrieben werden soll, den Arbeitenden jederzeit unterbrechen. Wie im echten Leben: Der lauteste Kunde wird sofort bedient, alle Arbeit wird sofort angefangen, es wird ständig zwischen den Arbeiten gewechselt. Das Ergebnis hier war schnell sichtbar: Es dauerte viel länger als geschätzt, Kunden wussten nicht, wann sie ihre Ergebnisse bekommen und für den Arbeitenden war es sehr stressig.

Anders Variante 2. Hier wurde jeder Name nacheinander geschrieben. Und überraschende Effekte sind eingetreten: Es war nicht nur viel weniger Stress, es wurde auch alles viel früher fertig! Kunden konnten vorhersehen, wie lange die Bearbeitung ihres Namens dauern würde und fühlten sich besser eingebunden.

Das Lernergebnis hier: Erkennen, dass mit weniger Arbeit im System nicht nur viel früher erste Ergebnisse geliefert (und damit auch bezahlt) werden, sondern auch der letzte Kunde bekam sein Produkt früher, als wenn sofort damit begonnen worden wäre. Es entsteht ein Gefühl für Wert (Value) und dass dieser nur dann erreicht wird, wenn der Kunde sein Produkt verwenden kann. Arbeit und Flow müssen gemanagt werden und dies geschieht durch Visualisierung, das Setzen von WIP-Limits (Work in Progress) und Messung.

Und noch etwas braucht es: Mut, Dinge anders zu machen. Das Motto “Mehr ist Mehr” ist tief verwurzelt und nach Bauchgefühl richtig. Es auszuhalten, zu warten, benötigt Mut. “Stop starting, start finishing” ist die neue Devise.

Wie funktioniert Zusammenarbeit?

Unsere Teilnehmenden bekamen die Aufgabe, eine Kette zu bilden und Lego-Steine von Hand zu Hand zu geben. Warum? Um zu sehen, wie überlastete Arbeitssysteme funktionieren.

Dazu durfte Bastian den Manager spielen: Möglichst viel und möglichst schnell neue Legosteine in die Hände der Arbeitsgruppe geben. Wie erwartet stieg das reine Arbeitstempo sofort enorm! Ein Manager wäre stolz gewesen: Da rührt sich was!

Doch sieht man genauer hin, fallen Dinge auf: Bausteine werden einfach möglichst schnell weitergegeben, egal, von welcher Hand sie kamen. Viele Teile fallen auf den Boden. Alle Hände quillen schnell mit Bausteinen über. Stress, Hektik und kein Überblick mehr. In der Rückfrage würde niemand so arbeiten wollen.

Und dennoch ist dieses System ein gutes Beispiel für das reale Leben. Bastian, unser Manager im Spiel, hat es noch realistischer gemacht: Seine Rückfragen, wie weit das Team denn wäre, haben immer wieder die Arbeit unterbrochen und, trotz bester Absichten, die Situation nur verschlimmert. Und auch hier wurde klar: Statusberichte und Schätzungen sind keine produktiven Arbeiten! Interessant war auch, dass eine anschließende Verdopplung der Mitarbeitenden pro Arbeitsstation das Gesamtergebnis nicht beeinflusst hat.

Daniel, unser Flow- und Kanban-Fachmann, konnte hier helfen. Statt Statusberichte zu verfassen, half ein Taskboard, welches jederzeit (auch für das Management) einen aktuellen Stand abbildet. Und durch das Einführen eines WIP-Limits von einem Legostein pro Hand konnte nachhaltig das Gesamtergebnis erhöht werden!

Wir konnten hier nachvollziehbar den Wert von strukturierter Kommunikation, Visualisierung, systemischer Optimierung und Messung zugänglich machen. Und spielerisch/selbstkritisch auf das tägliche Arbeitsleben blicken. Doch wie kann es teamübergreifend im echten Leben besser getan werden?

Transparenz, strukturierte Kommunikation und Visualisierung für erfolgreiche Zusammenarbeit

Eine passende Antwort sind Flight Levels (von Klaus Leopold). Anders als agile Skalierungsframeworks wie SAFE und LESS ändert es erst einmal nichts, sondern visualisiert nur. Damit zeigt es seine Kanban-Wurzeln. Bestehende Teams und Arbeitsweisen bleiben erst einmal erhalten.

Neu sind die drei Ebenen: Operativ, koordinativ und strategisch. Wo Teams auf der unteren Ebene ruhig mit Kanban oder Scrum weiter arbeiten können, wird die koordinative Ebene zum Retter. Dort, wo normalerweise eher eine Blackbox ist, kann mit einem Sichtbarmachen der Arbeit nun endlich Value angestrebt werden. Während Teams mit Stories ihre Arbeiten planen, fließen auf der koordinativen Ebene die Epics von Ende zu Ende. An ihnen hängen die Teams mit ihren Stories, so dass nun auch teamübergreifend koordiniert werden kann.

Auf allen Ebenen wird ständig geplant und priorisiert. Damit auch auf der koordinativen Ebene klar ist, wie die priorisierte Reihenfolge der Themen (Epics) ist, gibt es noch eine strategische Ebene darüber. 

Vergessen dürfen wir nicht, dass Menschen im Mittelpunkt dieser Arbeit stehen und gezielt miteinander kommunizieren müssen. Dies geschieht in sogenannten agilen Interaktionen, also Meetings, Gesprächen aber auch asynchrone Kommunikation z.B. über den Blick auf die Boards. Sogar Kunden und Stakeholder dazu nehmen? Nur zu, keine Angst!

Mit diesem Bild konnten wir einige Arbeitsabläufe simulieren und allen Beteiligten das Verständnis und Lust auf Flight Levels geben. Und das in kleinen Schritten: Für den Anfang tut es vielleicht ein übergreifendes Planungsmeeting und eine übergreifende Retrospektive.

Rahmenbedingungen für Veränderung

Für die Einführung von Flight Levels werden 5 Schritte empfohlen. Wir haben unsere Teilnehmenden gefragt, wie sie nach dem Training bewerten würden, wie weit sie gemäß dieser Schritte bereits sind. Wie zu erwarten, wurde im Verlauf des Trainings viel Problembewusstsein geschaffen, welches die Teilnehmer mit Grün bewertet haben. Eine wirkliche Visualisierung mittels Flight Levels, so waren sich alle einig, gibt es natürlich noch nicht (es ist also noch mehr rot). Die gemeinsame Verortung war wichtig, damit sich ein Fokus und ein Momentum entwickeln kann.

Wir haben in diesem Zusammenhang auch das Thema Agile-Leadership behandelt und wie wichtig es ist, dass die Führungsmannschaft ein Problem benennt und ein glaubhaftes Veränderungsmandat gibt und etwas vom Gas geht. So dass sich ein Change-Team aus Abgesandten der Teams bilden kann, um ein Flight-Level-System zu konzipieren. 

Besonders schön war der Moment, wo wir die Anwesenden fragten, ob sie neugierig sind und Flight Levels ausprobieren wollen. In diesem Moment waren alle Daumen nach oben!

Nächste Schritte und Randbedingungen

Während des Trainings wurde nach jedem Thema Zeit eingeräumt, das Gelernte zu verdauen. Getreu der 1:2:4:alle Liberating-Structure erst alleine, dann zu zweit und dann in Vierergruppen, die ihr Gelerntes präsentieren durften. So entstand eine Wand voller Anforderungen an den neuen Arbeitsmodus. Quasi die abhakbare Definition of Done. Ganz schön beeindruckend, was die Teilnehmenden in zwei Tagen alles mitgenommen haben!

Und so ergab sich auch das avisierte weitere Vorgehen:

• Die Führungsmannschaft benennt das Problem und gibt ein Mandat für Veränderung
• Ein Change-Team kommt zusammen, um das Flight Level System zu designen
• Parallel wird es darum gehen, den Produktschnitt zu verfeinern
• Und dann viel Ausprobieren, Lernen und Verbessern

Schlussfolgerung

Wir sind in den Workshop mit viel Unklarheit über den Verbesserungsfokus und die Notwendigkeit gestartet. Bei den Teilnehmenden stand hauptsächlich die eigene, lokale Optimierung im Vordergrund – und damit auch Skepsis, ob Agilität ihnen etwas bringen kann. Das hat sich im Laufe der zwei Tage stark geändert und die Sichtweise ist globaler geworden. 

Wir haben keine vorgefertigten Lösungen präsentiert, bei denen man nicht mehr denken muss. Und manchmal waren wir selbst die größten Kritiker an einer zu schnellen Lösung. Gemeinsam entstand damit ein Gefühl für die aktuelle und eine Vision einer zukünftigen Lage. Und dass die Teilnehmer diese auch selbst erreichen können, ohne dass ihnen die Kontrolle entzogen wird. Dass es nicht einfach wird, ist klar. Aber es ist auch nicht unmöglich, denn wenn man viele kleine Schritte hin zu dieser Lösung macht und sich mittels Messungen immer wieder verortet, dann schiebt sich dem Gehenden der Weg unter die Füße. 

Auch die Organisationskultur und die Angst vor Veränderungen wurden bearbeitet. Wirksame Veränderungsimpulse entstanden aus der Gruppe heraus, da sich alle das Gleiche vorgenommen hatten. Deshalb war es auch sehr hilfreich, dass die Führungsmannschaft mit im Training dabei war und danach als Sponsorenteam mit einem Coach die Veränderung weiter begleiten wird. 

Und so bleibt uns das Training in guter Erinnerung. Es wurde kritisch und offen, teilweise auch sehr direkt, aber immer fair und mit Spaß an der Sache diskutiert. Und das Gefühl zum Schluss, als alle Daumen nach oben waren, wird hoffentlich noch lange in positiver Erinnerung bleiben und dazu animieren, den eingeschlagenen Weg auch zu gehen. Ins Fliegen zu kommen. Wir bleiben dabei und helfen.