Direkt zum Hauptbereich

Ein Pfad durch den Skalierten Scrum Dschungel (10 Frameworks und ein Ratschlag)


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

leSS

Nexus

Spotify

Unfix

Scrum@Scale

Flight Levels

Und noch mehr DAD, Flow, FAST

Was tun, nun?


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/



Kommentare

  1. https://www.teamworkblog.de/2022/04/ein-pfad-durch-den-skalierten-scrum.html

    AntwortenLöschen
  2. Schade, 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

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Selbstbewertungsfragen für den Alltag in Arbeitsgruppen aus Sicht von Mitarbeitenden

Welche Fragen können wir Mitarbeiter:innen stellen, um herauszufinden, ob agiles Arbeiten wirkt? Es gibt bereits eine Menge an Fragebögen. Aber ich bin nicht immer zufrieden damit.

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Microsoft Lists: mit Forms und Power Apps komfortabel mobil arbeiten

In meinem Kundenkreis sind viele Menschen, die den Arbeitsalltag nicht vorwiegend auf dem Bürostuhl sitzend verbringen, sondern "draußen" unterwegs sind. Vielleicht in Werkstätten oder im Facility-Management. Es ist so wichtig, dass die Schnittstellen zu den Abläufen im Büro gut abgestimmt sind. Microsoft 365 hat so einiges im Baukasten, man muss es nur finden und nutzen.  In diesem Artikel spiele ich ein Szenario durch, das auf Microsoft Lists, Forms und - für die Ambitionierteren - Power Apps setzt.

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.

Wie Agilität den Kundennutzen steigert - Einige Argumente für Berater:innen

In Zeiten wirtschaftlicher Unsicherheit fragen sich viele, ob agile Beratung noch eine Zukunft hat. Die Antwort liegt in der konsequenten Orientierung am Kundennutzen. Qualität setzt sich durch, wenn sie messbare Verbesserungen bei Umsatz, Kosten und Leistungsfähigkeit bewirkt, anstatt sich in Methoden und zirkulären Fragen zu verlieren. Dieser Artikel zeigt, wie agile Beratung nachhaltige Veränderungen in Unternehmen schafft und warum gerade jetzt gute Berater:innen gebraucht werden, um Organisationen widerstandsfähiger zu machen.

Warum eine Agile Transformation keine Reise ist

Die agile Transformation wird oft als eine Reise beschrieben. Doch dieser Vergleich kann viele Unternehmen in die Irre führen oder Bilder von unpassenden Vergleichen erzeugen. Transformationen sind keine linearen Prozesse mit einem klaren Ziel, sondern komplexe und dynamische Entwicklungen. Dieser Artikel zeigt, warum Agilität kein Weg mit einem festen Endpunkt ist.

Warum bringen Warum-Fragen so wenig?

Frust! Wieder gibt's am Ende des Meetings keine Lösungen, sondern nur Diskussionen darüber, wer was warum verbockt hat. Wieder geht nichts voran. Warum passiert uns das immer wieder? (Ha! Da ist sie wieder, die Warum-Frage.)