+49 152 33 77 98 19
mail@marckaufmann.com
marckaufmann.commarckaufmann.com
  • Start
  • Über mich
  • Training
    • Professional Scrum Master (PSM I)
    • Professional Scrum Master – Advanced (PSM II)
    • Professional Scrum Facilitation Skills (PSFS)
    • AI Superkräfte für Scrum Master
    • —
    • Professional Scrum Product Owner (PSPO I)
    • AI Superkräfte für Product Owner
    • —
    • Professional Agile Leadership Essentials (PAL)
  • Coaching
  • Kundenstimmen
  • Blog
  • Kontakt
Back
  • Start
  • Über mich
  • Training
    • Professional Scrum Master (PSM I)
    • Professional Scrum Master – Advanced (PSM II)
    • Professional Scrum Facilitation Skills (PSFS)
    • AI Superkräfte für Scrum Master
    • —
    • Professional Scrum Product Owner (PSPO I)
    • AI Superkräfte für Product Owner
    • —
    • Professional Agile Leadership Essentials (PAL)
  • Coaching
  • Kundenstimmen
  • Blog
  • Kontakt
  • Home
  • Blog
  • Blog
  • Ein Pfad durch den skalierten Scrum Dschungel (10 Frameworks und 1 Ratschlag)

Blog

18 Apr

Ein Pfad durch den skalierten Scrum Dschungel (10 Frameworks und 1 Ratschlag)

  • In Blog, lean thinking, Scrum

„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ältst Du davon?“

Teilnehmerstimmen

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 Modell
Unfix Modell
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 von agilen Teams mittels 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 arbeiten. 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.

Bildquelle: https://www.scaledagileframework.com/

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 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.

Bildquelle: https://less.works/

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 zu 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

Bildquelle: https://www.scrum.org/

So wie in LeSS bleiben auch im Nexus – das Skalierungsframework der Scrum.org – die Kernelementen von Scrum von zentraler Bedeutung. Auch im Nexus wird das One-Team Scrum 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 im Wesentlichen durch die Größe der Egos ihrer Erfinder 🙂

Spotify Modell – 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 Spotify Modell

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.

Bildquelle: https://unfix.work/

Scrum @ Scale – Jeff Sutherlands Vorschlag

Jeff Sutherlands Vorschlag um Scrum zu skalieren.

Bildquelle: https://www.scrumatscale.com/

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). S@S bietet einen komponentenbasierten Ansatz an, in dem zunächst das verbessert wird, wo die meisten Schwierigkeiten liegen.

Flight Levels

„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)

Klaus Leopold

– so erklärt Klaus Leopold, der Erfinder der Flight Levels, sein Modell.

Bildquelle: https://leanability.com/

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. Disciplined Agile (DA) , oder das Flow Framework (Mik Kersten) (hier ein guter Talk), oder FAST

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 ist das Beste für unsere Organisation?

Wenn ein agiles Team bereits im komplexen Raum operiert 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 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/

(Coverphoto von Lisa Kessler // Unsplash)

Tags:lessnexuss@ssafescaledscrumspotifyunfix
  • Share:
Marc Kaufmann

You may also like

Weekly Wisdom

Weekly Wisdom: Maybe. The Story of a Chinese Farmer (Alan Watts)

  • 30/04/2025
  • by Marc Kaufmann
  • in agile mindset
Recently I stumbled upon a short story told by Alan Watts, which got me thinking:
Agile Castle Camp Community 25
Agile Castle Camp 2025 – it’s a wrap!
16/04/2025
Was Bettenmachen mit Führung zu tun hat
24/03/2025
Sprint Review - again?
Sprint Reviews: Zeitverschwendung oder echtes Highlight? 6+ kreative Ideen, die deine Teilnehmer lieben werden
09/02/2025

Leave A Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Categories

  • agile mindset
  • Blog
  • Books
  • Developer
  • downloads
  • events
  • games
  • Leadership
  • lean thinking
  • Other
  • Product Owner
  • Scrum
  • Scrum Master
  • self-organization
  • Solution Focus
  • tool
  • tough scrummer
  • Video

Recent Posts

Weekly Wisdom
Weekly Wisdom: Maybe. The Story of a Chinese Farmer (Alan Watts)
30Apr,2025
Agile Castle Camp Community 25
Agile Castle Camp 2025 – it’s a wrap!
16Apr,2025
Was Bettenmachen mit Führung zu tun hat
24Mar,2025

Tags

accountabilities Advent agile mindset agiles arbeiten agilität anforderungsmanagement Coaching conference entscheidungen treffen events facilitation führung gratefulness kanban kommunikation leadership life-hack Lösungsfokus non-violent communication opener product backlog product owner psm psm2 q&a refinement Reflexion scaledscrum scrum scrumday Scrum Master self-organization simulation solution focus Sprint Review systems thinking talk teamwork tools tough scrummer training ukraine video vortrag workshop

Kontakt

+49 152 33 77 98 19

mail@marckaufmann.com

Q2 App24, Tigne Point, Sliema, SLM3190, Malta

Mehr

  • Über mich
  • Andere über mich
  • Anfrage stellen
  • Impressum
  • Datenschutz
  • Trainings AGB

Social Links

  • Twitter
  • Linkedin

Komm in meinen Tribe

Werde Teil der Community of Experts.

© 2025 flowww.org ltd. All rights for marckaufmann.com are reserved.

  • Kontakt
  • Impressum & Datenschutz
  • Trainings AGB