Skalierte Agilität — wo es hakt und warum...

Es gibt viele Frameworks bzw. Ansätze, um zu skalierter Agilität zu kommen. Den größten “Marktanteil” dabei hat das Scaled Agile FrameworkSAFe. Daneben gibt es LeSSScrum@ScaleNexusDSDM und Kanban-Skalierungsysteme (Stichwort: Flightlevels).

Allen gemein ist, dass sie ein strukturelles Schaubild zeigen, hier z.B. die Struktur- und Ablaufbilder von LeSS, Scrum at Scaleund SAFe.

 

Scrum@Scale Framework

 

LeSS Framework

 

SAFe 5 for Lean Enterprises

 

Diese Schaubilder, die Struktur und Ablauf zeigen, sind verführerisch: Die Umsetzung ist scheinbar leicht, man bildet Teams, die in gewissen Rhythmen arbeiten und Touchpoints haben für Planung, Integration und Feedback/Lernen. Ich habe in der freien Wildbahn noch nie eine Organisation gesehen, die es nicht hinbekommt, diese Strukturen und Meeting-Zyklen auf die Beine zu stellen. Viel seltener habe ich leider funktionierendes Scaled Agile und Business Agility erlebt. Warum ist das so?

 

Struktur ist einfach

Ich behaupte: Struktur ist einfach. Aber nur die halbe Miete, vermutlich weniger. Es ist wie bei Scrum, zu dem es heißt: Scrum ist simple, but it’s not easy. Wenn das schon auf Team-Level (bei Scrum) so ist, wie ist es dann erst in der Skalierung?! 

Nehmen wir SAFe als Beispiel. Grün im Schaubild habe ich die Parts markiert, die m.E. leicht umzusetzen sind: Teams definieren, PI-Planning alle drei Monate ansetzen, Rollen vergeben.

 

 

Rot dagegen hab ich die Dinge markiert, die m.E. gern unter den Tisch fallen. Und wir bewegen uns erst in der Essential-Ausprägung von SAFe, darüber gibt es noch Solution-Ebene und Portfolio-Ebene. Wird es dann einfacher? 

Nehmen wir den Klassiker “Lean and Agile Leadership”: Von Leffingwell & Co. bewusst in die Basis gepflanzt, weil halt unbedingt nötig… als Basis… damit es klappt mit dem Scaled Agile. Wie viel wird investiert, so dass Führungsleute — bzw. alle! — sich eine neue Form des Leadership aneignen?

Nehmen wir “Agile Product Delivery”. Oft wird, Hand aufs Herz, den Leuten, die vorher IM Produkt-Team waren, ein neues Label auf die Brust geheftet und nun sind sie Product Owner oder agile Produktmanager. Ich war lange PO. Ich hab viel gelernt unterwegs, mit Freude, aber auch mit Schmerzen und auch nicht ohne Verluste. Und v.a. mit Investment (Zeit, Geld). Wird das sauber gemacht bei SAFe-Einführungen? Leffingwell sagt “Train everyone”, aber (a) reden wir da über ein Zwei-Tage-Training, das allein begrenzte Wirkung hat und (b) habe ich nie erlebt, dass alle Personen und einer SAFe-Implementierung die passenden Trainings durchlaufen. 

Nehmen wir “Team and Technical Agility”. Teams werden aus Experten gebildet, im besten Falle sind sie cross-funktional, aber — wie jeder weiß — erstens sind acht oder neun Leute, die man zusammensteckt, nicht auf Knopfdruck ein Team; und zweitens sind sie kein agiles Team, wenn sie nicht vorher substanziell Erfahrung mit Team-Agilität gesammelt haben. Diese Erfahrung zu sammeln kostet Zeit. Eventuell auch Geld. Also Investment.

Nehmen wir “Core Values”, “SAFe Principles” und “Lean and Agile Mindset”. Ich will nicht stänkern, aber lasst uns mal zehn zufällig aus einigen SAFe-Implementierungen rekrutierte Leute interviewen, welche Core Values und Prinzipien das sein könnten — und wie der Lean and Agile Mindset aussieht… wenn da etwas Überzeugendes rauskommt, geb ich dem gesamten Release Train einen aus!

 

Ohne Investment keine reiche Ernte

Um nicht zu nerven, möchte ich nicht noch über DevOps-Kompetenzen, gute Produkt-Roadmaps und gelungene Vision sprechen, die zu erarbeiten ebenfalls ein Investment ist, das man nicht unterschätzen darf. Worüber ich abschließend aber sprechen will, ist: 

Wir dürfen keine Agilität und keine (oder kaum ;) Erfolge und keine bahnbrechende Veränderung erwarten, wenn wir nur die einfachen, sichtbaren strukturellen und prozessualen Aspekte umsetzen. Wenn wir nicht in alles investieren, was skalierte Agilität ausmacht. Das wäre doch, wie wenn wir die Wände und Streben für einen Wolkenkratzer hochziehen und das als Haus verkaufen. Die Stockwerke, die Sanitäranlagen, die Aufzüge und die Möbel haben wir weggelassen.

Aus der Hüfte geschossen, denke ich mir, es geht bei skalierter Agilität um die Faktoren Kultur, Praktiken, Struktur und Outcome. (Der Outcome wir auch gern vernachlässigt. Wenn wir supi agil sind, aber nicht liefern… was heißt das dann?!)

 

 

Nur Praktiken ohne Struktur bringen Zufallsergebnisse. Nur Struktur ohne Kultur bringt Zombie Agile. Nur Kultur ohne Praktiken bringen keine Outcomes. Und ohne Outcomes ist alles vergeblich. Investieren wir also richtig, dann können wir die Früchte von skalierter Agilität ernten. Ansonsten, fürchte ich, nicht. 

Interessieren Sie sich für agile Skalierung, Business Agility und das Scaled Agile Framework? Buchen Sie unser Training "Leading SAFe", das Sie zum zertifizierten SAFe Agilist® macht.

Autor

Agile Transformation heißt ständige Erneuerung.

Sprechen Sie mit uns über Ihren Weg in die digitale Zukunft, wir freuen uns drauf!

Autor

Sacha StorzAgile Coach