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

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Leitlinien-Werkstatt für Microsoft-Teams

Mittlerweile hat Microsoft Teams in sehr vielen Unternehmen einen Platz gefunden. Es bedient den Wunsch nach schneller Kommunikation und gemeinsamer Datei-Bearbeitung. Und spart damit Zeit und unnötige Prozessschleifen. Oder? 

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

Die Krankheit des Besser-Wissens! Drei powervolle Fragetechniken und eine Haltung zur Heilung.

Kennst Du das: Du betrittst einen Raum und bist Teil einer Situation, hörst eine Problembeschreibung, siehst eine Aufgabe oder liest eine Anfrage. Auf jeden Fall weisst Du mit einem Blick, einem Satz, einem Augenzwinkern sofort Bescheid. Du weisst: um was es geht was das Problem ist wieso das passiert ist was als Nächstes passiert und oft auch was dann (nicht) zu tun ist So wie mit dem Video hier: Ziemlich klar oder? Was für Gedanken gehen Dir durch den Kopf? Vielleicht sowas wie Oh weh!, Unfall!,  gibts Verletzte?  Oder Gehts denen gut? Wo ist das passiert? Viel Spass beim Flottmachen! Etc, etc... Auf jeden Fall aber: Was für ein Malheur! - oder irgend etwas Anderes in der Art. oder? Anderes Beispiel. Schau Dir mal folgendes Bild an und les im Geiste die beiden Reihen vor: A-B-C 12-13-14 oder? Unser Geist beruft sich auf sein Wissen und gibt uns in sekundenschnelle seine Annahme, seine Interpretation, seine Projektion der Wirklichkeit ein. Und die ist in dem Video oben nunmal ein ve

Nur was sichtbar ist, kann gemanagt werden

Ihr steckt fest? Langsam wird’s brenzlig? Ihr wisst nicht so recht, was tun? Kleiner Tipp: Nur was sichtbar ist, kann gemanagt werden.