Und wie mache ich es, wenn mehrere Teams mit Scrum arbeiten sollen?Bei uns soll die ganze Firma mit Scrum arbeiten. Wie beginnen wir?Wie gehen wir am Besten damit um, wenn wir teamübergreifend agil werden wollen?Wir setzen in der Firma SAFe ein – was hälst Du davon?
In beinahe jedem meiner Professional Scrum Master Trainings werden solche und ähnliche Fragen zum Thema „Skaliertes Scrum“ gestellt.
Das Framework Scrum selbst sagt wenig über die Art und Weise wie man es im Enterpriseumfeld erfolgreich einsetzt.
Und doch ist der Bedarf an Lösungen wie man firmenweit agil zusammenarbeiten kann riesig. Inzwischen gibt es eine Reihe an Skalierungsframeworks die versuchen, diesen Bedarf zu decken.
In diesem Blogpost geb ich eine Übersicht über die unterschiedlichen Ansätze und Frameworks und versuche damit einen Pfad durch das unübersichtliche Dickicht der Frameworks zu schlagen.
Die bekanntesten Skalierungsframeworks:
SAFe - one size fits all?
Das Scaled Agile Framework gehört zu den bekanntesten agilen Skalierungsframeworks. Es versucht die Komplexität der Skalierung mit mehr Struktur Herr zu werden.
Es kommt mit drei – bei großen Initiativen sogar mit vier -strukturellen Ebenen daher.
Ganz unten ist die Teamebene, die stark angelehnt an Scrum arbeitet. Die Ebene drüber – die Programmebene – versucht die Arbeit der Teams vorzustrukturieren und in Teambacklogs einzugeben. Das synchronisierende Element teamübergreifend ist der sogenannte Agile Release Train (ART), in dem die zugehörigen agilen Teams miteinander kollaborieren und in den sie gemeinschaftlich zuliefern.
Bei sehr grossen Vorhaben gibt es als nächstes die sogenannte Solutionebene die mehrere ARTs synchronisiert.
Über allem steht die sogenannte Portfolioebene, die auf Konzernebene Themen identifiziert, priorisiert und „grünes Licht“ für die ARTs gibt.
Der Vorteil von SAFe ist das mehr an vorgegebener Struktur und das daraus vermeintlich einfacher abzuleitende organisatorische Zielbild. Die Vielzahl an Rollen gibt dem Unternehmen zudem die Möglichkeit ihre bestehenden Rollen und Positionen auch dem Zielbild zuzuordnen. Das unterstützt ein Wiederfinden seiner derzeitigen Rolle und wirkt Widerstand entgegen. Viele der angebotenen einzelnen Konzepte des Frameworks (PI Planning, Customer Centricity, Lean-Agile Leadership & Principles, Value Streams, ..) sind an sich sinnvoll, wenn auch in der vorgegebenen Struktur aus meiner Sicht nur eingeschränkt implementierbar.
Und das ist auch der Hauptkritikpunkt von SAFe aus meiner Sicht: zu starre, vorgegebene Strukturen.
SAFe vermittelt mit den angebotenen Strukturen aus meiner Sicht ein vermeintliches Gefühl der Sicherheit.
Im Komplexen gibt es keine Kochrezepte. SAFe als kontextfreies Kochrezept und organisatorische Blaupause zu nutzen ist daher gefährlich.
Die Vielzahl an abzubildenden Rollen, Events und Praktiken bringt ein erhebliches Mehr an Komplexität und Starrheit mit, die die eigentliche Flexibilität die durch Agilität ja im Unternehmen erreicht werden soll aus meiner Sicht oft eher behindert als entwickelt.
Ich habe SAFe Implementierungen gesehen, die erfolgreich waren, weil die Teams Professional Scrum implementieren konnten, und Verbesserungen aus der Teamebene heraus in die höheren Ebenen bringen konnten.
Und ich habe mehr SAFe Implementierungen gesehen, die aufgrund des Overheads der starken Vorgaben mit sehr viel Reibungsverlusten, Verschwendung, Abhängigkeiten, Frustration und grossem Unmut auf Teamebene zu kämpfen hatten.
LeSS - do more with less!
Wenn SAFe Skalierung mit zusätzlichen Ebenen versucht anzugehen, ist Large Scale Scrum (LeSS) sehr viel stärker an Scrum orientiert.
Das zentrale Leitmotiv in LeSS ist: do more with less.
LeSS konzentriert sich auf einen leichtgewichtigen ganzheitlichen Produktansatz in dem sich Teams um Produkte herum organisieren. 9 weitere Prinzipien geben Orientierung für einen ganzheitlichen, empirischen, kundenzentrischen Ansatz mit Fokus darauf durch kontinuierliche Verbesserung Wert zu schaffen. Die Kernelemente von Scrum (empirische Prozesskontrolle, Selbstmanagement, Crossfunktionalität, Kommunikation) bleiben hier von zentraler Bedeutung.
Zu den klassischen Scrum Elementen kommt ein gemeinsames Planungsevent und eine teamübergreifende Teamretrospektive hinzu. Für alle weitere zusätzliche Kommuniktion empfiehlt LeSS: einfach miteinander zu sprechen, im Code kommunizieren, Traveler zu implementieren sowie Open Spaces und Community of Practices zu nutzen. (1)
Meine persönliche Erfahrung mit LeSS ist: es funktioniert :-). Die Einfachheit und Eleganz des Frameworks funktioniert - auch wenn das Etablieren der Prinzipien mühsam ist und Disziplin erfordert.
Nexus - das Skalierungsframework der Scrum.org
So wie in LeSS bleiben auch im Nexus die Kernelementen von Scrum von zentraler Bedeutung. Auch im Nexus wird das Scrum Framework mit teamübergreifenden Events angereichert um so mit der steigenden Komplexität und den Abhängigkeiten zwischen den Teams umzugehen. Auch hier wird ein gemeinsames Sprint Planning und eine teamübergreifende Retrospektive etabliert. Zudem gibt es das Nexus Integration Team (NIT) – ein dediziertes Team bestehend aus Abgesandten der einzelnen Scrum Teams. Die Aufgabe des NIT besteht darin, die Scrum Teams dabei zu unterstützen, das Inkrement in einem potentiell auslieferbaren Zustand innerhalb der Sprints zur Verfügung stellen zu können. (2)
Witzbolde sagen, LeSS und Nexus unterscheiden sich daher im Wesentlichen durch die Größe der Egos ihrer Erfinder :-)
Spotify Model - ein Zielbild, kein Framework
Zu den bekannteren Skalierungsmodellen gehört auch das Spotify Model. Nicht zuletzt dadurch, dass Spotify sehr offen in der Dokumentation und Kommunikation ihrer Vorgehensweise waren. So gibt es eine ganze Reihe von Videos auf Youtube (hier und hier) zu sehen, die einen guten Einblick in die Vorgehensweise geben.
Das Spotify Model bietet ein Organisationsmodell einer agilen Matrixstruktur an, das den Schwerpunkt auf Teamautonomie und Produktfokus legt. Es sagt wenig über Alignments und Zusammenarbeit zwischen den Teams.
Ich hab das Spotify Modell in einigen Organisationen gesehen. Oft wird die Matrixstruktur kopiert („Squads, Tribes, Chapters etc“). Genauso oft finde ich genau die unbeschriebenen Punkte zu Teamautonomy vs. Teamalignment, (& Verantwortlichkeit) als Schwierigkeiten dieser Organisationen vor.
Das Modell ist nicht ohne Kritik. Interessanterweise kritisieren die Autoren selbst einiges, und warnen vor blinden Copy & Paste. (3)
Unfix Modell - der Newcomer
Die Schwierigkeiten, die das Spotify Modell nicht addressiert versucht das Unfix Modell anzugehen
“The unFIX model pinpoints many of the problems we saw (and mostly fixed) at Spotify. Specifically, this provides more flexibility to fit different organizations, and more clear guidance on how to scale beyond a few hundred people.”
(Anders Ivarsson, co-author of “the Spotify model”)
Neben anderen Namen bei z.T. gleicher Funktion – Squads werden Crews, Product Owner werden Captains, Chapters werden Forums, Tribes werden Bases usw. – achtet das Unfix Modell mehr auf Alignment zwischen den Teams mittels Experience Crews (Value Stream orientiert), Platform Crews (Technologie orientiert) und Governance. (4)
Anders als das Spotify Modell erwähnt das Unfix Modell auch Dynamic Reteaming Ideen und ist mehr auf Remote Arbeit ausgelegt – man merkt, das das Jüngste der Skalierungsmodelle während Covid entstanden ist.
Scrum @ Scale - Jeff Sutherlands Vorschlag
Jeff Sutherlands Vorschlag um Scrum zu skalieren.
Wenig überraschend sieht man in Scrum@Scale Konzepte aus Scrum wieder. Iterative Herangehensweise, das "Was" (Product Owner Cycle) und das "Wie" (Scrum Master Cycle) ist in der Verantwortlichkeit getrennt. S@S etabliert teamübergreifende Koordination mittels Scrum of Scrums, in dem sich Abgesandte der einzelnen Teams regelmässig treffen sowie zwei Führungskreise, das Enterprise Action Team (EAT), das sich um prozessuale, und das Executive MetaScrum (EMS) das sich um fachliche Entscheidungen teamübergreifend kümmert.
S@S führt zwei weitere Rollen (den Scrum of Scrums Master und den Chief Product Owner) und gemeinsame, skalierte Events ein (Scaled Planning, Scaled Daily Scrum, Scaled Review, Scaled Retrospective sowie ein Scaled Backlog Refinement).
Im Gegensatz zu den Skalierungsframeworks oben bietet S@S einen komponentenbasierten Ansatz an, in dem zunächst das verbessert werden soll, wo die meisten Schwierigkeiten liegen. Mitblogger Peter Fischbach hat auf diesem Blog dazu bereits etwas geteilt
https://www.scrumatscale.com/scrum-at-scale-guide-online/
Flight Levels - agile Organisationsentwicklung
„Das Modell der Flight Levels ist ein Kommunikationsinstrument, um die Wirkung von spezifischen Verbesserungsschritten auf unterschiedlichen Ebenen deutlich zu machen und herauszufinden, wofür eine Organisation der sinnvolle und/oder mögliche Ausgangspunkt liegt, um eine Verbesserung zu starten“ (5)
– so erklärt Klaus Leopold der Erfinder der Flight Levels sein Modell.
Streng genommen sind Flight Levels daher kein Skalierungsframework sondern ein Instrument für agile Organisationsentwicklung.
Flight Levels basieren auf Kanban, das mit seinem Prinzip „Beginne mit dem was Du jetzt machst, visualisiere, limitiere gleichzeitige Arbeit, optimiere“ evolutionäre und nicht revolutionäre Veränderung ermöglicht - daher oft mit weniger Widerstand zu tun hat.
Die Metapher hinter Flight Levels bezieht sich auf die Flughöhe eines Unternehmens. Je höher man fliegt, desto einfacher behält man die Übersicht. Je tiefer man fliegt, desto mehr Details werden sichtbar. Das Modell arbeitet auf drei Ebenen: Flight Level 1 optimiert die Zusammenarbeit auf operativer (Team-)Ebene. Flight Level 2 kümmert sich auf teamübergreifender Ebene um die Optimierung des Wertstroms durch bessere Interaktion/Koordination zwischen den Teams. Und Flight Level 3 ermöglicht einen strategischen Blick auf alle Value-Streams, Produkt- und Projektinitiativen der Organisation mit dem Ziel das Gesamtergebnis des Unternehmens zu optimieren.
Und da ist noch mehr:
Wem das noch nicht genug ist, kann sich auch weitere Skalierungsimpulse holen: z.B. von Disciplined Agile (DA), oder aus dem Flow Framework von Mik Kersten (hier ein guter Ted-Talk von ihm), oder aus FAST, um noch ein paar mehr zu nennen.
Was tun, nun?
Inzwischen gibt es eine Vielzahl von Frameworks um Agilität im Enterprise Umfeld abzubilden. Bei der Fülle an Frameworks drängt sich eine Frage auf: Welches sollen für die Organisation ausgewählt werden?
Wenn ein agiles Team bereits im komplexen Raum operiert, so ist der Prozess des Skalierens über Teams hinweg in der Komplexität um ein Vielfaches höher. Eine einfache Antwort, eine Blaupause, ein Kochrezept kann es hier daher nicht geben.
Einen robusten Ratschlag dennoch an dieser Stelle: Egal wie (und ob überhaupt) skaliert wird: die zugrundeliegenden Ideen und Kernelemente, das agile Gedankengut mit den Werten und Prinzipien sowie die empirischen Prozesskontrolle sind für erfolgreiche echte Agilität im Unternehmen von zentraler Bedeutung.
Um erfolgreich zu sein, muss das verstanden und von den Teams selbst erlebt werden. Idealerweise in kleinen Schritten.
Egal welches Framework zur Skalierung ausgewählt wird, es muss sichergestellt sein, das die Grundlagen klar sind und ein gemeinsames Verständnis an der Basis für die Basis entstehen kann.
Gute Gelegenheiten diese Grundlagen zu schaffen können Professionelle Scrum Trainings sein. Auch der Austausch mit und der Anschluss an andere innerhalb der Scrum Community wird oft als hilfreich wahrgenommen. Gerade (Un-)Konferenzen wie der Scrum-Day oder die Agile Coach Camps in Deutschland oder Österreich können helfen, um in den Austausch zu kommen und um dann erste Versuche in der Skalierung selbst zu starten - und eigene Erfahrungen zu sammeln.
Wie sieht es mit Dir aus? Welches der Frameworks oben hat Dich am meisten angesprochen? Welches fehlt? Und über welches willst Du mehr erfahren? Schreib es mir in die Kommentare!
Mehr:
(1) https://less.works/less/framework
(2) https://www.scrum.org/resources/blog/uberblick-uber-das-nexus-framework
(3) https://www.jeremiahlee.com/posts/failed-squad-goals/
(4) https://unfix.work/blog/lets-unfix-spotify
(5) https://www.leanability.com/de/blog/2017/04/flight-levels-die-verbesserungsebenen-der-organisation/
https://www.teamworkblog.de/2022/04/ein-pfad-durch-den-skalierten-scrum.html
AntwortenLöschenSchade, dass Kanban als Skalierungsframework nicht ausdrücklich erwähnt wird. Wäre schön gewesen, den mit Kanban lässt sich sehr gut in der Breite, Tiefe, Höhe skalieren und dies sogar mit wenig "Wasserkopf".
AntwortenLöschen