Blog

Scaled Scrum
Skalierungs-Frameworks im Vergleich

Was können Nexus, LeSS, SAFe, Scrum@Scale und das Spotify-Modell?

Das passende Skalierungs-Framework wählen

Wenn Unternehmen mit mehreren agilen Teams an einer Lösung - einem Produkt oder einem Service - arbeiten wollen, fehlt häufig das Wissen und die Erfahrung, wie die Skalierung der Teams gestartet und zielführend gemanagt werden sollen. Als Leitfaden zur agilen Skalierung wurden verschiedene Skalierungs-Frameworks entwickelt, die je nach Kontext hilfreich sein können. Doch welches passt am besten zu Ihrem individuellen unternehmerischen Kontext?

Wir haben die gängigsten agilen Skalierungs-Frameworks für Sie unter die Lupe genommen und eine Übersicht zur ersten Orientierung erstellt:

Nexus Framework

Was ist das Nexus Framework?

Nexus ist eine leichtgewichtige Erweiterung des Scrum Frameworks, mit dessen Hilfe mehrere Scrum Teams gemeinsam ein Produkt entwickeln. Das Nexus Framework hilft, typische Skalierungsprobleme zu lösen - wie beispielsweise das Aufrechterhalten eines hohen Maßes an Selbstmanagement, Transparenz und Ergebnisverantwortung (Accountability) sowie die Minimierung von Abhängigkeiten zwischen den einzelnen Teams.

Entwickelt wurde das Nexus Framework von Ken Schwaber und Scrum.org, beschrieben wird es im Nexus Guide, dem Leitfaden zur Skalierung von Scrum mit Nexus.

Wie funktioniert das Nexus Framework?

Ein Nexus fasst in etwa drei bis neun Scrum Teams zusammen, die an der Entwicklung eines Produktes arbeiten, indem sie mindestens einmal in jedem Sprint gemeinsam ein integriertes Increment erstellen. Der Wert dieses Produktes wird von einem Product Owner verantwortet, der dazu ein Product Backlog managt. Unterstützt werden die Scrum Teams durch das Nexus Integration Team, das aus dem Product Owner, einem Scrum Master sowie ausgewählten Mitgliedern der Scrum Teams besteht und ergebnisverantwortlich für integrierte Increments gemäß der Definition of Done des Nexus ist.

Einige der Scrum Events werden durch Nexus Events ergänzt oder ersetzt, um die Aktivitäten aller Scrum Teams im Nexus zu koordinieren: Im Nexus Sprint Planning planen Mitglieder aus allen Scrum Teams und der Product Owner gemeinsam den Sprint. Im Nexus Daily Scrum werden von Vertretern aller Scrum Teams Integrationsprobleme und Abhängigkeiten besprochen und Fortschritte in Richtung des Nexus Sprint Goals aufgezeigt. Im Anschluss finden die Daily Scrums der Scrum Teams statt, mit Fokus auf Lösung der zuvor transparent gemachten Integrationsprobleme. Im Nexus Sprint Review inspiziert der Nexus gemeinsam mit Stakeholdern das integrierte Increment sowie den Fortschritt zum Product Goal und erarbeitet zukünftige Verbesserungen des Produktes. In der Nexus Sprint Retrospective planen die Scrum Teams, wie der gesamte Nexus effektiver wird. In den Sprint Retrospectives besprechen die einzelnen Scrum Teams, wie sie effektiver werden und wie sie Probleme lösen können, die ihr Team sowie den gesamten Nexus betreffen.

Quelle: https://www.scrum.org/resources/online-nexus-guide (abgerufen: 10-Nov-2021)

Wann sollte man das Nexus Framework einsetzen?

Das Nexus Framework eignet sich für die Skalierung, wenn das bestehende Scrum Team bereits regelmäßig wertvolle Done Increments erstellen kann und alle Maßnahmen zur De-Skalierung (siehe Tipp Nr. 3) ausgeschöpft hat.

Die Vorteile und Nachteile des Nexus Frameworks in der Übersicht

Unsere Erfahrung mit Nexus lässt uns zu folgender Bewertung kommen:

Vorteile des Nexus Frameworks

Der größte Vorteil von Nexus liegt in dessen Leichtgewichtigkeit: Ein Scrum Team, das die Praktiken und Prinzipien von Scrum sicher beherrscht und regelmäßig Done Increments erstellen kann, wird das Nexus Framework ohne größere Schwierigkeiten einsetzen können - ohne dass Scrum etwas von der eigenen Leichtgewichtigkeit und Agilität verliert.

Nachteile des Nexus Frameworks

Die Leichtgewichtigkeit von Nexus kann jedoch auch zum Nachteil werden: Es sollte keinesfalls der Eindruck entstehen, dass sich die Teams mit dem Nexus Framework oder Scrum nicht intensiv beschäftigen müssen oder Elemente weglassen können, ohne dass es Auswirkungen auf die Wirksamkeit hätte. Daher ist gerade zu Beginn die Unterstützung durch einen Scrum Master mit Nexus-Erfahrung empfehlenswert. In unserer Case Study „Scrum skalieren mit dem Nexus Framework” berichten wir über unsere Erfahrung mit dem Nexus Framework.

Large Scale Scrum (LeSS)

Was ist das LeSS Framework?

Das Large Scale Scrum Framework (LeSS) versteht sich als eine tatsächliche Skalierung von Scrum. Denn während viele andere Frameworks so konzipiert sind, dass sie Scrum zwar integrieren (können), hat LeSS den Anspruch, weiterhin Scrum in seiner Ursprungsform zu sein - nur eben skaliert.

Entwickelt wurde das LeSS Framework von Craig Larman und Bas Vodde.

Wie funktioniert das LeSS Framework?

LeSS ist gemacht für zwei bis acht Scrum Teams, die gemeinsam ein Produkt entwickeln und dafür die gleichen Scrum Events nutzen. Jedes Team besteht dabei aus Entwickler:innen und einem Scrum Master. Da alle Teams gemeinsam an einem Produkt arbeiten, gibt es weiterhin nur einen Product Owner, der die Ergebnisverantwortung für das Produkt trägt und hierfür ein Product Backlog managt.

Dennoch stechen folgende zwei Änderungen von LeSS heraus:

  1. Das Planning findet in zwei Schritten statt: Im Planning 1 kommen alle Teams zusammen und entscheiden gemeinsam, welche Features im nächsten Sprint von welchem Team umgesetzt werden. Im anschließenden Planning 2 ziehen sich die einzelnen Teams zurück, um für sich einen Plan zu entwickeln, wie sie die Arbeit im Sprint erledigen werden.

  2. Die Review wird wiederum von allen Teams gemeinsam durchgeführt. So wird sichergestellt, dass nicht nur die Stakeholder Feedback zum jeweiligen Increment geben können, sondern auch gleichzeitig alle Teams wissen, was entwickelt wurde. Um die Zusammenarbeit zwischen den Teams zu verbessern, wird in Ergänzung zur Team Retrospective zusätzlich eine teamübergreifende Retrospective durchgeführt.

  3.  
Quelle: https://less.works/ (abgerufen: 22.11.2021)

Wann sollte man das LeSS Framework einsetzen?

LeSS eignet sich für Teams, die bereits Erfahrung mit Scrum haben und diese Vorteile auch weiterhin nutzen möchten, ohne eingeschränkt zu werden. Auch wenn sich Ihre Organisationsstrukturen längst im Wachstum befinden, kann Ihnen LeSS dabei helfen, diese Strukturen zu vereinfachen - durch Deskalierung statt Skalierung - denn: Sie benötigen keine weiteren Rollen, Events oder Artefakte neben denen des Scrum Frameworks.

Die Vorteile und Nachteile des LeSS Frameworks in der Übersicht

Unser Team kommt hinsichtlich des LeSS Frameworks zu folgender Empfehlung:

Vorteile des LeSS Frameworks

Haben Sie in Ihrer Organisation bereits ein reifes Scrum Team, das kontinuierlich Wert liefert, können Sie mit LeSS schnell skalieren, ohne neue Strukturen schaffen zu müssen. Dadurch sparen Sie nicht nur Kosten und Zeit, sondern auch das Alignment der beteiligten Menschen ist sehr hoch. LeSS kann Ihnen andererseits auch dabei helfen, kompliziert gewachsene Strukturen abzubauen und organisatorische Konstrukte zu vereinfachen. Durch den Einsatz von Feature Teams sparen Sie sich zudem das Managen von Abhängigkeiten, da jedes Team für sich entwickeln kann.

Nachteile des LeSS Frameworks

Aus letztgenanntem Vorteil entsteht allerdings auch ein entscheidender Nachteil: Denn LeSS gibt Ihnen keine Hilfestellung an die Hand, wie Sie vor Ende des Sprints die Feature Increments der einzelnen Teams zu einem potentiell auslieferbaren, integrierten Product Increment zusammensetzen können. Diese Herausforderung wird der Selbstorganisation der Teams überlassen, was jedoch einen hohen Reifegrad voraussetzt. Genauso ist es bei der täglichen Zusammenarbeit. Hier ist jeder Einzelne dafür verantwortlich, den Austausch zwischen den Teams selbst zu fördern.

Scaled Agile Framework (SAFe)

Was ist das SAFe Framework?

Das Scaled Agile Framework (SAFe) ist ein umfangreiches Rahmenwerk, das einen weiteren Weg aufzeigt, wie Unternehmen skalieren können. Es verwendet sowohl Prinzipien und Praktiken aus der agilen und der Lean-Software-Entwicklung, als auch aus dem Systemdenken und Design Thinking.

Entwickelt wurde SAFe von Dean Leffingwell und Scaled Agile, Inc.

Wie funktioniert das SAFe Framework?

SAFe baut sich durch drei verschiedene Ebenen auf, die implementiert werden können:

  1. Die Grundlage bildet die Essential-Ebene. Hier wird ein minimales Set von Rollen, Events und Artefakten implementiert, um mit Hilfe von agilen Teams kontinuierlich Business-Lösungen fertigzustellen. Dabei können die Teams wählen, ob sie Scrum, Kanban, XP oder eine Kombination davon verwenden. Jedes Team muss in seinen Iterationen eine Reihe von Regeln und Praktiken befolgen, wie zum Beispiel die „built-in quality”. Alle Beteiligten zusammen (agile Teams, Release Train Engineer, System Architect, Product Management und Business Owners) bilden einen Agile Release Train (ART).

  2. Die Large-Solution-Ebene erweitert die Essential-Ebene um zusätzliche Rollen, Praktiken sowie weitere Orientierungshilfen. So können mehrere Agile Release Trains koordiniert und zu einem Solution Train zusammengeschlossen werden. Hierbei helfen das Solution Management, der Solution Architect und der Solution Train Engineer (STE).

  3. Die Portfolio-Ebene schließt die Lücke zur Strategie und organisiert einen oder mehrere Wertströme. Hierzu gehört auch die Fähigkeit und Kultur einer Organisation, fortwährend zu lernen. Auch hier werden zusätzliche Rollen, Events und Artefakte eingeführt.

Es können auch alle SAFe-Ebenen (full configuration) gleichzeitig implementiert werden. Dies bietet sich besonders bei großen Unternehmen an, um Wertströme zu identifizieren und in regelmäßigen Iterationen Wert zu schaffen.

Quelle: https://www.scaledagileframework.com/wp-content/uploads/delightful-downloads/2021/01/Scaled-Agile-Framework_Portfolio_A4-2.pdf (abgerufen: 11-Nov-2021)

Wann sollte man das SAFe Framework einsetzen?

SAFe ist von allen agilen Frameworks das schwergewichtigste - und steht damit zunächst einmal im Widerspruch zum Grundverständnis von Agilität. Daher empfehlen wir Ihnen, das SAFe Framework erst dann für Ihr Unternehmen in Betracht zu ziehen, wenn Sie sich bereits empirisch bewiesen haben, dass Sie Ihre Teams nicht durch ein leichtgewichtigeres agiles Framework effektiv skalieren können.

Die Vorteile und Nachteile des SAFe Frameworks in der Übersicht

Wir bewerten SAFe wie folgt:

Vorteile des SAFe Frameworks:

Ein durchaus positiver Aspekt von SAFe ist die Autonomie der Teams: Sie können selbst entscheiden, ob sie Scrum, Kanban, XP oder eine Kombination daraus einsetzen wollen. Durch festgelegte Rollen und Verantwortlichkeiten sowie vorgeschriebene Praktiken, Events und Artefakte erhalten Unternehmen außerdem klare Vorgaben an die Hand.

Nachteile des SAFe Frameworks:

Die vielen Rollen, Artefakte, Events und Regeln von SAFe können jedoch auch einen Nachteil darstellen: Sie erschaffen nicht nur einen hohen (Schulungs-) Aufwand. Zudem erwecken sie den Anschein, dass durch SAFe Planungssicherheit in komplexen Sachverhalten geschaffen wird, die naturgemäß nur eingeschränkt vorhersagbar und planbar sind. Daraus entsteht auch die Gefahr, dass SAFe unreflektiert angewendet wird, ohne dessen „Fit” für die eigene Organisation und deren Kontext zu berücksichtigen.

Sie sind von der Vielzahl der Möglichkeiten überrascht und wissen nicht genau welches Framework für Sie passt? Erzählen Sie uns von Ihrer Organisation und Ihrer Herausforderung - wir beraten Sie gerne!

Sprechen Sie uns an!

Scrum@Scale

Was ist Scrum@Scale?

Das Framework Scrum@Scale hilft Scrum Teams und sogenannten Netzwerken von Scrum Teams, an gemeinsamen Zielen zu arbeiten. Scrum@Scale zielt darauf ab, häufig beobachtete Skalierungsprobleme zu lösen. Hierfür werden die Funktionsweise und die Struktur eines einzelnen Scrum Teams auf mehrere Scrum Teams übertragen. Der durch die Skalierung steigende Management-Aufwand soll dabei möglichst gering gehalten werden.

Dr. Jeff Sutherland, einer der Scrum-Erfinder, und Scrum Inc. haben Scrum@Scale entwickelt und das Framework im Scrum@Scale Guide beschrieben.

Wie funktioniert Scrum@Scale?

Ausgangspunkt und Referenz für Scrum@Scale ist ein funktionierendes Scrum Team, das mindestens einmal jeden Sprint ein Increment liefert. Mehrere Scrum Teams bilden zusammen ein Scrum of Scrums (SoS). Mehrere Scrum of Scrums ergeben wiederum ein Scrum of Scrum of Scrums (SoSoS). Die Scrum Events und Rollen - beziehungsweise Verantwortungen - werden in einem Scrum of Scrums ebenfalls skaliert. So verfügt ein Scrum of Scrums auch über die Rolle des Scrum of Scrums Masters (SoSM) und ein Product Owner Team mit einem Chief Product Owner (CPO).

Quelle: https://www.scrumatscale.com/scrum-at-scale-guide-online/ (abgerufen: 24.11.2021)

Als weitere Besonderheit stechen zwei Teams heraus, die dafür sorgen, dass ein oder mehrere SoS effektiv zusammenarbeiten und integrierte Increments liefern können:

  1. Das Executive Meta Scrum Team (EMS) konzentriert sich darauf, WAS ein SoS oder SoSoS entwickelt. Es fokussiert also auf die Produktvision und das Product Backlog. Teil dieses Teams sind immer auch der oder die Chief Product Owner.
  2. Das Executive Action Team (EAT) fokussiert wiederum darauf, WIE ein SoS oder SoSoS schneller werden kann. Es konzentriert sich also auf den Prozess und die Impediments. Als Transformationsteam trägt das EAT die Ergebnisverantwortung (Accountability) eines Scrum Masters - nur eben auf Organisationsebene, die aus den SoS und SoSoS besteht. Es setzt sich aus einem Scrum Master, einem Product Owner und weiteren Mitgliedern zusammen, die gemeinsam fähig und ermächtigt sind, die agile Organisation weiterzuentwickeln.
  3.  
Quelle: https://www.scrumatscale.com/scrum-at-scale-guide-online/ (abgerufen: 24.11.2021)

Die Effektivität eines oder mehrerer Scrum of Scrums messen Sie im Scrum@Scale durch Metriken. Diese geben Ihnen Aufschluss über den Produktwert (Product Feedback) und über die Lieferfähigkeit (Release Feedback). Scrum@Scale schlägt hierzu einige Metriken vor, um Transparenz herzustellen, ohne diese Metriken jedoch vorzuschreiben.

Wann sollte man Scrum@Scale als Framework einsetzen?

Scrum@Scale bietet ein Framework für den Umgang mit einer großen Anzahl von Teams und Netzwerken von Teams. Damit ist es für Sie insbesondere für die agile Entwicklung von einem umfassenden Produktportfolio interessant. Gleichzeitig basiert das Framework aber auf der Mindestanforderung, dass Ihr erstes Scrum Team - die Referenz der gesamten Skalierung - erfolgreich und regelmäßig Done Increments ausliefert. Denn wenn das erste Scrum Team, oder das erste Scrum of Scrums, diese Mindestanforderung nicht erfüllt, werden die vorhandenen Dysfunktionen mit großer Wahrscheinlichkeit ebenfalls skaliert und dadurch alle Teams sowie deren Produkte in Mitleidenschaft gezogen.

Die Stärken und Schwächen von Scrum@Scale in der Übersicht

Wir bewerten Scrum@Scale folgendermaßen:

Vorteile von Scrum@Scale

Scrum@Scale eignet sich für Sie, wenn Sie bereits reife agile Teams in Ihrer Organisation entwickelt haben. Es baut auf dem Scrum Framework auf und fördert die Bildung von Netzwerken aus Teams. Einen entscheidenden Vorteil sehen wir im Executive Action Team (EAT): Ist das EAT autorisiert und fähig, Impediments zu beseitigen, ohne das Selbstmanagement der Scrum Teams einzuschränken, bedeutet dies einen großen Gewinn an Effektivität und kann die Agilität der gesamten Organisation enorm steigern.

Nachteile von Scrum@Scale

Die vielen Events und Rollen, die mit einer linearen SoS- oder SoSoS-Skalierung einhergehen, erhöhen die Komplexität in der Kommunikation enorm und könnten als Nachteil ausgelegt werden. Daher ist aus unserer Perspektive eine hohe Reife aller Teammitglieder zwingend erforderlich - und zwar sowohl vom CPO und SoSM, als auch von den Mitgliedern des EMS und EAT sowie der Scrum Teams. Damit keine permanente Abhängigkeit zum EAT geschaffen und dieses dadurch zum „Flaschenhals“ wird, muss das EAT aus Personen bestehen, die ausreichend autorisiert, reif und erfahren sind, um das Selbstmanagement von Teams konsequent zu fördern.

Spotify-Modell

Was ist das Spotify-Modell?

Der Audio-Streaming-Dienst Spotify wuchs seit seiner Gründung im Jahr 2006 so rasant hinsichtlich Mitarbeitenden und Nutzerzahlen, dass sich das Unternehmen dazu entschied, verschiedene agile Methoden zu einem eigenen Organisationsmodell weiterzuentwickeln. Im Jahr 2012 stellten Henrik Kniberg & Anders Ivarsson die daraus entstandene Struktur vor, die seither als das Spotify-Modell gehandelt wird.

Wie funktioniert das Spotify-Modell?

Das Spotify-Modell bildet innerhalb des Unternehmens Squads, Tribes, Chapter und Gilden:

  • Squads sind autonome und crossfunktional besetzte agile Teams bestehend aus acht bis zehn Personen – vergleichbar einem Scrum Team. Sie bilden die Basis des Spotify-Modells und sind völlig frei in der Wahl ihrer Methoden und Prozesse. Den einzigen Rahmen bilden die langfristigen Ziele und Prinzipien der Organisation sowie die vom Product Owner gesetzten Prioritäten zur Erreichung der strategischen Roadmap.
  • Tribes sind ein Zusammenschluss von Squads, die einen gemeinsamen Kontext bearbeiten – beispielsweise ein Produkt oder eine Dienstleistung. Für die optimale Arbeitsumgebung und den Austausch unter den zu einem Tribe gehörenden Squads zeichnet der Leiter des Tribes, der Tribe Lead, verantwortlich.
  • Chapter bestehen aus Mitgliedern eines Tribes, die über dieselben Kompetenzen verfügen und auf unterschiedliche, multidisziplinäre Squads aufgeteilt sind. Hier kommen also Mitarbeitende eines Fachgebiets zusammen, die sich unter der Leitung einer Chapter-Führung regelmäßig zum Wissenstransfer treffen.
  • Gilden (Guilds) fassen wie Chapter eine Gruppe von Mitarbeitenden desselben Fachbereichs zusammen, die sich allerdings über die Grenzen ihrer Tribes hinweg fachlich vernetzen.
  •  
Quelle: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf (abgerufen: 15.11.2021)

Wann sollte man das Spotify-Modell einsetzen?

Das Spotify-Modell gibt viel Freiraum bei der Gestaltung der eigenen Organisation und setzt daher einen fortgeschrittenen „agilen Reifegrad” für eine effektive Anwendung voraus. Dennoch kann dieses Modell als Orientierung helfen, die Silos im eigenen Unternehmen durch cross-funktionale Teams auf der einen Seite und fachliche Organisation auf der anderen Seite aufzulösen.

Die Vorteile und Nachteile des Spotify-Modells in der Übersicht

Wir bewerten das Spotify-Modell wie folgt:

Vorteile des Spotify-Modells

Der Vorteil des Spotify-Modells liegt in der Klarheit und Einfachheit der beschriebenen Strukturen: Der „Produkt”-Fokus der cross-funktionalen Squads und Tribes wird durch die fachlichen und organisatorischen Netzwerke der Chapter und Gilden kombiniert. Die Skalierung erfolgt dabei über die Anzahl der Tribes und kann somit individuell an das eigene Unternehmen angepasst werden.

Nachteile des Spotify-Modells

Der größte Nachteil des Spotify-Modells ist aus unserer Sicht das Missverständnis, dass es sich dabei um ein allgemeingültiges Skalierungs-Framework handele, was von Spotify selbst so nie gedacht war. Vielmehr zeigt das Spotify-Modell lediglich die Momentaufnahme einer individuellen Anwendung agiler Prinzipien und Praktiken, die Spotify seit dessen Vorstellung auch stetig weiterentwickelt hat. Und so ist es nicht weiter verwunderlich, aber dennoch bemerkenswert, dass Spotify dieses Modell so nicht mehr anwendet. Daher empfehlen wir auch hier einen bedachten Einsatz des Modells für das eigene Unternehmen, das dann mit konkreten agilen Praktiken ergänzt werden muss, um wirksam zu werden.

Gemeinsamkeiten der Frameworks für agile Skalierung

Skalierungs-Frameworks sollen Ihnen dabei helfen, die Agilität Ihrer Teams und Organisation zu fördern und weiterzuentwickeln. Entscheidend bei der Wahl des für Sie passenden Frameworks ist folglich der „agile Reifegrad“ Ihres Unternehmens.

Für Unternehmen, die bereits fortgeschrittener in der eigenen Agilität sind, bietet sich eher ein leichtgewichtiges Framework an. Denn hier werden wenig Vorgaben gemacht und stattdessen auf agile Prinzipien und stetige eigene Verbesserungen gebaut. Weniger fortgeschrittene Unternehmen sollten zunächst einzelne agile Teams mit einem hohem Reifegrad entwickeln, bevor sie skalieren.

 

Viele Frameworks, viele Möglichkeiten

Sie sind von der Vielzahl der Möglichkeiten überrascht und wissen nicht genau welches Framework für Sie passt? Erzählen Sie uns von Ihrer Organisation und Ihrer Herausforderung - wir beraten Sie gerne!

Sprechen Sie uns an!

Autor: