Scaling Scrum – Skalierte Scrum Frameworks im Vergleich

Scrum ist ein agiles Arbeitsmodell für ein einzelnes Team (One Team Scrum) mit maximal 8-10 Personen. Dazu definiert der Scrum Guide Verantwortungen, Aktivitäten und Werkzeuge für die optimale Gestaltung der Zusammenarbeit. Dagegen definiert skaliertes Scrum, wie Du diese Prinzipien über eine Vielzahl von Teams oder sogar eine gesamte Organisation ausweitest. Dabei ist die wesentliche Herausforderung, Abhängigkeiten zwischen Teams bei der gemeinsamen Entwicklung eines Produktes zu managen und einen optimalen Arbeitsfluss sicherzustellen. Ohne dabei jedoch das wichtige Scrum Prinzip autonomer Teams zu verletzen.

Auch wenn sich die skalierten Scrum Rahmenwerke in wichtigen Details unterscheiden, triffst Du auf folgende prinzipielle Gemeinsamkeiten.

1. Scaling Scrum ist Scrum: Die grundlegenden Ideen von Scrum findest Du in alle skalierten Scrums wieder. Das heißt, wenn Du bereits Scrum etabliert hast, ist das ein prima Startpunkt, um Scrum über eine Vielzahl von Teams zu skalieren.

2. Scrum Teams: Einzelne Teams arbeiten nach Scrum. Das heißt, Entwickler sind fest einem Team zugehörig und jedes Scrum Team wird von einem Scrum Master gecoacht. Bei der Besetzung der Product Owner Rolle verfolgen die skalierten Scrum Rahmenwerke jedoch unterschiedliche Ansätze. 

3. Gemeinsamer Sprint: Skaliertes Scrum heißt, dass alle Teams in einem gemeinsamen Sprint arbeiten.

4. Skalierte Events: In allen skalierten Scrum Rahmenwerken werden Scrum Events zusätzlich zu einer Team- auch teamübergreifend auf einer Organisationsebene abgehalten. Damit etablieren skalierte Scrum Rahmenwerke ein zweites Flight Level, um die Abhängigkeiten zwischen Teams zu koordinieren und Teams zu synchronisieren. 

5. Neue Rollen: Aufgrund der Größe der Organisation werden je nach skaliertem Scrum auch unterstützend neue Rollen definiert. Diese Rolle ergänzen die etablierten Scrum Rollen.

6. Gemeinsame Artefakte:  Die Werkzeuge und Vereinbarungen sind im skalierten Scrum mit einem One Team Scrum identisch. Im Scaling Scrum ist natürlich die besonders spannende Frage, wie Du eine gemeinsame Definition of Done über eine Vielzahl von Teams synchronisierst.

Skaliertes Scrum dient vor allem dazu, Abhängigkeiten von Teams zu managen. Diese Abhängigkeiten entstehen durch das Arbeiten an einem gemeinsamen Produkt und einer gemeinsamen Codebasis. Dabei sollen einzelne Scrum Teams weitgehend autonom arbeiten können, gleichzeitig jedoch gemeinsame Arbeiten verrichten. Deswegen solltest Du dir vor der Einführung skalierten Scrums erst einmal bewusst machen, wie Du Abhängigkeiten durch eine entsprechende Software-Architektur, durch ein Decoupling und durch eine entsprechende Besetzung der Teams per se reduzieren kannst. Schließlich bräuchtest Du kein skaliertes Scrum, wenn es gelänge, Abhängigkeiten auf Null zu reduzieren. 

Umgekehrt folgt aus den vorgenannten Gründen, dass ein Wachstum deiner Organisation nicht zwingend zur Skalierung von Scrum führen muss. Denn solange es keine Abhängigkeiten zwischen Scrum Teams gibt oder Du Abhängigkeiten durch eine entsprechende Team Topologie (z.B. einem Plattform Team) weitgehend auflösen kannst, brauchst Du nicht über die Skalierung von Scrum nachzudenken. Was nicht heißt, dass Du nicht doch auch wichtige Anregungen aus den nun folgenden skalierten Scrum Rahmenwerken mitnehmen kannst.

Für die Skalierung vom Scrum findest Du in der Praxis drei gängige Rahmenwerke.

• Nexus von Scrum Gründer Ken Schwaber, für 3 bis 9 Teams. Für mich der einfachste Einstieg in skaliertes Scrum, wenn auch wenig verbreitet.
• Scrum@Scale vom zweiten Scrum Gründer Jeff Sutherland, sehr gute Ansätze was die Verzahnung mit nicht agilen Organisationseinheiten angeht.
• LeSS von Bass Vode, ich mag es für seine systemische Sichtweise, die Fokussierung auf “one product” und sein simples Motto “LeSS is more”. 

Ich stelle dir die Rahmenwerke mit den wichtigsten Punkten kurz vor. In unserem Cheatsheet findest Du eine einfache Gegenüberstellung, in weiterführenden Artikeln kannst Du dich dann vertieft einlesen.

Nexus (lat.Verknüpfung) ist das skalierte Scrum des Scrum Erfinders Ken Schwaber. Folgende wesentlichen Konzepte zeichnen Nexus aus:

• Ein Nexus entspricht 3 bis 9 Scrum-Teams
• Ein Nexus hat nur einen Product Owner
• Nexus definiert ein neues Team, das Nexus Integration Team (NIT) 
• Team Events: Alle Events bis auf die Review
• Nexus Events zusätzlich zu Team Events: Cross Team Refinement, Nexus Sprint Planning, Nexus Daily,  Review (für alle Teams), Nexus Retro 

Eine Besonderheit des Nexus ist sicherlich das Nexus Integration Team (NIT), das aus dem PO, einem Scrum Master und Spezialisten der Entwicklungsteams besteht. Das NIT hat die Aufgabe, eine reibungslose technische Integration der Arbeitsergebnisse aller Teams zu ermöglichen. Dazu berät und befähigt das NIT die jeweiligen Entwicklungsteams bei der Integration ihrer Arbeitsergebnisse, das NIT ist also am ehesten mit einem “Enabling Team” zu vergleichen.

In unserem Artikel zu Nexus findest Du weitere Details zu diesem Scaled Scrum Rahmenwerk. Den offiziellen Nexus Guide findest Du in unterschiedlichen Sprachen hier.

Scrum@Scale ist das skalierte Scrum des zweiten Scrum Gründers Jeff Sutherland. Folgende wesentliche Konzepte zeichnen Scrum@Scale aus:

• Scrum@Scale verfolgt eine sehr konsequente Skalierung von Scrum, d.h. jedes Team besteht nach wie vor aus einem PO, Entwicklern und einem Scrum Master.
• Jede Organisation kann beliebig nach oben skaliert werden: Mehrere Scrum Teams werden in einem “Scrum of Scrum” (SoS) synchronisiert, die SoS werden wiederum in einem “Scrum of Scrum of Scrums” (SoSoS) koordiniert. 
• Team Events: Alle Events bis auf die Review
• Skalierte Scrum Events: Executive Meta Scrum, Scaled Backlog Refinement, Scaled Planning, Scaled Daily Scrum, Scaled Review, Scaled Retrospective
• Neue Rollen / Teams: Executive Action Team (EAT) und das Executive Meta Scrum (EMS)

Bemerkenswert und sehr besonders an dieser Scaled Scrum Variante finde ich das Executive Action Team (EAT) und das Executive Meta Scrum (EMS). Das Executive Action Team (EAT) ist sozusagen die Skalierung der Scrum Master Rolle, kümmert sich also um die Beseitigung organisatorischer Blockaden und die agile Transformation der gesamten Organisation. Dagegen werden im “Executive Meta Scrum” inhaltliche Prioritäten definiert und dann über die Product Owner in die Scrum@Scale Organisation getragen. Diese beiden Gruppen und dazugehörige Events ermöglichen eine ganzheitliche und strategische Entwicklung der Organisation. Auch Führungskräfte, die nicht Teil des Scrum@Scale Organisation sind, können diesen Kreisen angehören. So sichert Scrum@Scale die Verbindung in die “nicht agilen” Organisationseinheiten.

In diesem Artikel findest Du eine ausführliche Einführung zu Scrum@Scale. Den offiziellen Scrum@Scale Guide findest Du in unterschiedlichen Sprachen hier.

LeSS ist für mich der "Rock'n'Roller" im Scaled Scrum. Dabei zeichnet sich LeSS durch folgende wesentliche Konzepte aus:

• LeSS ist für 2-8 Scrum Teams designt, LeSS Huge für mehr als 8 Teams. 
• LeSS reduziert auf das Wesentliche (“Descaling”) und gibt den umsetzenden Teams viel Autonomie. 
• Es gibt nur einen Product Owner
• Team Events: Alle Events bis auf die Review
• Skalierte LeSS Events: Overall Backlog Refinement Overall Retrospektive

Dabei folgt LeSS einer sehr systemischen Sichtweise und macht empirisches Lernen bzw. Experimente zu einer expliziten Säule des LeSS Rahmenwerks. In diesem Artikel kannst Du dich vertiefend zum LeSS Rahmenwerk einlesen. Den offiziellen LeSS Guide findest Du hier.

Das Spotify Modell ist im Kern ein organisatorischer Rahmen und nicht “out of the box” ein skaliertes Scrum. Den Kern der Spotify Organisation bilden Squads als agile Teams mit 8-10 Personen. Tribes sind der Zusammenschluss mehrerer Squads und über Chapter etabliert das Spotify Modell eine ergänzende, fachliche Führung. Wenn Du das Spotify Modell als organisatorischen Rahmen nutzen möchtest, dann bleiben folgende Fragen noch immer unbeantwortet:

• Wie gehst Du mit der Rolle des Product Owners um?
• Wie gestaltest Du skalierte Events für eine optimale Kommunikation und Synchronisation der Teams?

Damit dient das Spotify Modell maximal als Ergänzung zu den hier vorgestellten skalierten Scrum Rahmenwerken. Wenn Du die aber richtig anwendest und einsetzt, dann brauchst Du wiederum das Spotify Modell nicht. Der einzige wertvolle Gedanke am Spotify Modell ist die Idee, eine disziplinarische und fachliche Führungslinie (“Chapter”) zu etablieren. Diesen Gedanken findest Du ebenfalls in der Helix Organisation, d.h. auch dafür brauchst Du das Spotify Modell nicht. 

Bei der Einführung und Etablierung eines skalierten Scrums würde ich grob in diesen Schritten vorgehen:

1. Ein One Team Scrum etablieren und konsequent nach Scrum arbeiten. 
2. Mehrere Teams nach Scrum arbeiten lassen und ergänzend die ersten skalierten Plannings, Retros und eine gemeinsame Demo machen.
3. Für ein paar Sprints eigene Erfahrungen sammeln.
4. Im Rahmen von Workshops die hier vorgestellten skalierten Scrums diskutieren und abwägen. Ergänzt in jedem Fall um das Flight Level Modell und Team Topologies.
5. Für ein skaliertes Scrum entscheiden. Anfangen, Lernen und Anpassen.

Natürlich hat jede Organisation und jede Softwarearchitektur ihre eigene Historie und Besonderheiten. So ist die Wahrscheinlichkeit relativ hoch, dass es trotz der vielen Konzepte der skalierten Scrums noch unbeantwortete Fragen gibt. Da gehst Du dann ganz agil vor: Beobachten, Hypothesen und Erwartungen formulieren, lernen und anpassen. Ohne dich dabei gerade am Anfang zu weit von den skalierten Scrums zu entfernen. 

Egal, welche Scaled Scrum Variante dir mehr zusagt: Scrum Skalierung ist Scrum. Entsprechend heißt Scaling Scrum mit Scrum konsequent auf Teamebene zu etablieren. Wenn Du das ganz im Sinne des ShuHaRi konsequent und ordentlich machst, bieten dir die skalierten Scrums die verschiedensten Highlights. Für eine große Organisation ab 5 Teams bin ich persönlich ein großer LeSS Fan. Darunter würde ich mich eher bei Nexus bedienen, einfach weil es leichter und einfacher ist. Wenn deine Organisation in einen größeren, nicht agilen Kontext eingebettet ist, dann würde ich mir aus Scrum@Scale in jedem Fall Konzepte wie das Executive Meta Scrum und das Executive Action Team leihen. Wenn Du dabei Hilfe brauchst dann meld dich gerne.

Viel Erfolg dabei.