Scrum At Scale – die wichtigsten Infos zum agilen Skalierungsansatz

Management Summary

• Scrum at Scale ist ein Ansatz die Produktentwicklung mittels Scrum auf (theoretisch) beliebig viele Teams zu skalieren.
• Das Rahmenwerk unterteilt in einem Product Owner – dem ‚Was‘ – und einem Scrum Master – dem ‚Wie‘ – Zyklus. Auf Basis von Scrum werden zusätzliche Rollen, Ergebnistypen und Besprechungstermine zum Zwecke der Koordination eingeführt.
• Scrum at Scale darf im kommerziellen Umfeld frei verwendet werden. Die offizielle Webseite bietet teilweise auch deutschsprachiges Material zum kostenfreien Download.

Scrum at Scale – oft auch Scrum@Scale mit dem ‚@‘ Zeichen, ScrumAtScale zusammengefasst bzw. Scrum at Scale Framework – ist ein agiler Ansatz, um das parallele Vorgehen von nach Scrum agierenden Entwicklungsteams zu koordinieren. Im Scope sind dabei nicht nur Entwicklungsabteilungen, sondern alle Bereiche die arbeitsteilig Produkte hervorbringen.

Scrum at Scale hebt agiles Arbeiten von Einzelprojekt auf Programm- bzw. Organisationsebene. Nicht zwangsläufig muss das Ergebnis dabei ein Softwareprodukte sein. Der 21-seitige Scrum@Scale® Guide versteht unter ‚Produkt‘ jede Form von System, also gleichsam Prozesse, Services, Hardware etc..

Dabei schreibt sich das Framework folgende Eigenschaften ganz oben auf die Fahne (bzw. vorn in den dazugehörigen Guide)

• Leichtgewichtig – minimale überlebensfähige Bürokratie
• Einfach verständlich – ausschließlich Scrum Teams
• Schwierig zu meistern – Umsetzung eines neuen Betriebsmodells erforderlich

Ende 2019 ist Scrum at Scale in der Version 1.05 verfügbar, das geistige Eigentum steht unter einer Creative Commons 4.0 Attribution-Sharealike Lizenz.

Im Kern besteht Scrum at Scale aus zwei parallel verlaufenden Prozessen:

• Einem Product Owner Zyklus, der das ‚Was‘ des Produktes definiert sowie
• einem Scrum Master Zyklus, der das ‚Wie‘ der Entwicklungsarbeiten festlegt.

Beide Prozesse berühren sich an zwei Punkten: den Team-Level Prozessen sowie den Produkt & Release Feedback.

Product Owner Zyklus

Konzentrieren wir uns zunächst auf das ‚Was‘. In jedem nach Scrum arbeitenden Entwicklungsteam verantwortet ein Product Owner ein Teil des Produkts. Die Product Owners von bis zu fünf Scrum Teams finden sich in einem Product Owner Team zusammen, ein sogenannter Chief Product Owner (CPO) fungiert als oberster Repräsentant. Gemeinsam arbeiten die Product Owner eine Produktvision & -roadmap sowie eine Definition of Done heraus. Zudem identifizieren Sie Abhängigkeiten und Redundanzen mit Hilfe eines gemeinsamen Product Backlogs. Übersteigt die Produktgröße 25 entwickelnde Teams, dann wird ein Executive MetaScrum (EMS) ins Leben gerufen. Diese oberste Instanz setzt die strategischen Prioritäten und Ziele für das Gesamtergebnis.

Elemente und Beziehungen von Scrum at Scale (Quelle: www.scrumatscale.com)

Scrum Master Zyklus

Kommen wir nun zum ‚Wie‘ Zyklus. Scrum at Scale sieht bis fünf Scrum Teams ein Scrum-of-Scrums (SoS) Team vor. Dieses verantwortet die Ablieferung eines integrierten Produkt-Inkrements zum Sprintende. Ein Scrum-of-Scrums Master (SoSM) stellt dabei die Einhaltung von Scrum at Scale in allen Teams sicher. Sein Fokus liegt insbesondere auf organisatorischer, prozessualer und inhaltlicher Integration. Steigt Produktumfang und -komplexität weiter an, ist damit eine größere Entwicklungsmannschaft erforderlich, wächst Scaled at Agile weiter zum Scrum-of-Scrums-of-Scrums Ansatz. Das Limit liegt nun bei 25 synchronisierten Teams. Nun ist ebenfalls ein Execution Action Team (EAT) bestehend aus einem Product Owner und Scrum Master erforderlich. Ausgestattet mit einem politischen Mandat und ausreichendem Budget verantwortet und optimiert das EAT organisationsübergreifend die Ablaufqualität von Scrum auf Basis eines Organizational Transformation Backlogs.

Transparenz & Metriken

Sowohl die Product Owner als auch die Scrum Master legen organisationsspezifische Metriken fest. Der Scrum@Scale® Guide empfiehlt mindestens vier Größen zu messen und nachzuhalten:

• Produktivität – z.B. Veränderungsrate in der Produktausbringung per Sprint
• Wertelieferung – z.B. Geschäftswertgenerierung pro Einheit von Teamaufwand
• Qualität – z.B. Fehlerrate oder Zeiten von Servicestillständen
• Nachhaltigkeit – z.B. Teamzufriedenheit

Nutzen Sie die Vorschläge als Inspirationsquelle für Ihre Metriken. Forcieren Sie ebenfalls Transparenz, beispielsweise durch Kanban Boards oder geeignete Software Tools.

Zusätzlich zu den regulären Scrum Meetings und Sprints sieht Scrum at Scale auf einer höheren Ebene weitere Ereignisse und Abläufe vor.

Skalierung des Product Owner Teams – links ein MetaScrum von 5 Teams, rechts ein MetaScrum von 25 Teams (Quelle: www.scrumatscale.com)

Das Product Owner Team führt eine Verfeinerung des gemeinsamen Product Backlog im Rahmen von Backlog Decomposition & Refinement Terminen durch. Außerdem werden inhaltliche Hindernisse und Abhängigkeiten aufgespürt und Beseitigungsmaßnahmen beschlossen. Im Excecutive MetaScrum Event werden einmal pro Sprint Richtungsentscheidungen bzgl. Produkt, Anforderungen, Finanzierung, Personal, Ressourcenallokation und Kundenzusammenarbeit getroffen.

Skalierung des Scrum Master Teams – links ein Scrum-of-Scrums von 5 Teams, rechts ein Scrum-of-Scrums-of-Scrums von 25 Teams (Quelle: www.scrumatscale.com)

Im Scaled Daily Scrum (SDS) stellt das Scrum-of-Scrums Team sicher, dass sich die Teams täglich über Fortschritt, Hindernisse und Folgeschritte austauschen. Schließlich sorgt eine Scrum-of-Scrums Retrospective mit ausgewählten Vertretern dafür, dass sich die Vorgehenskompetenz verbessert und gute Praktiken Eingang in alle Entwicklungsteams finden.

Der Scrum@Scale® Guide rät, erst mit einer organischen Skalierung zu beginnen, sobald Scrum auf Einzelteamebene reibungsfrei funktioniert. Der Grundgedanke dahinter ist klar. Kleine Defizite im Scrum Ablauf sorgen für große Defizite im Scrum-of-Scrums Vorgehen. Erst wenn das sogenannte Referenzmodell trägt, sollten die Entwicklungsmannschaft mittels Scrum at Scale liniear vergrößert werden. Zudem schlägt der Guide eine Teamgröße von 5 Personen vor. Grundlage für diese Personaldecke ist eine Harvardstudie aus 2002.

Vorteile

• Scrum at Scale ergänzt den erprobten Ansatz Scrum um ausgewählte Ergebnistypen, Regeln, Rollen und Ablaufstrukturen. Wenden Sie Scrum bereits an, dann sollte eine Pilot-Skalierung auf 3 Teams im Bereich des machbaren liegen.
• Jeff Sutherlands Ansatz der agilen Skalierung besitzt in Größe und Umfang (theoretisch) keine Grenzen. Ob 3 oder 30 Teams – die Grundidee von Scrum-of-Scrums(-of-Scrums usw.) bleibt identisch.
•  

Nachteile

• Den Scrum at Scale Ansatz auf Nicht-IT-Abteilungen auszurollen benötigt aus unserer Sicht Zeit und Fingerspitzengefühl. Anders als die Software Engineers und IT-Betriebseinheiten sind Vertrieb, Marketing, Personalwesen und Forschungsbereiche mit einer agilen Entwicklung nach Scrum oft nicht bzw. nur vage vertraut.
• EAT, SDS, SoSM, MetaScrum… – vielleicht verwirren Sie die vielen neuen Konzepte von Scrum at Scale etwas. Kleiner Trost: Auch wir hatten zu Beginn unserer Auseinandersetzung mit dem Rahmenwerk mit der Begriffsflut zu kämpfen.

Dr. Jeff Sutherland ersann das ‚Meta-Level-Framework‘ Scrum at Scale und stellte dieses 2018 erstmalig der Öffentlichkeit vor. Sutherland – vormals Krebsforscher und Medizinprofessor –  entwarf den Ansatz analog einem biologischen Organismus. Wie ein organischer Körper skaliert auch Scrum at Scale aus einer einzigen Zelle heraus. Sutherlands Lehre und Forschung in den Feldern biologische Organismen, dynamische Systeme und objektorientierte Architekturen prägten entscheidend die Strukturen des skalierten Scrum Vorgehens.

Bemerkenswert sind ebenfalls die Parallelen zu Ken Schwabers Laufbahn. Die zwei US-Amerikaner Sutherland und Schwaber unterzeichneten 2001 das Manifest für Agile Softwareentwicklung. Anschließend trieben beide die Arbeiten am agilen Ansatz Scrum voran. Auch heute noch stehen Sutherland und Schwaber zusammen hinter dem Scrum Guide. Bei der Skalierung von agiler Entwicklung kam es jedoch zum inhaltlichen und wirtschaftlichen Bruch. Ken Schwaber konzipierte mit seinem Unternehmen Scrum.org das Nexus™ Framework, Jeff Sutherland ersann mit seiner Organisation Scrum Inc. den Ansatz Scaled At Agile. Beide Ansätze fußen auf Scrum, unterscheiden sich jedoch von der vorgeschlagenen Aufbau- und Ablauforganisation.

Heute bieten sowohl die Scrum Alliance als auch Sutherlands Scrum Inc. Training, Prüfung und Zertifizierung zum Certified Scrum@Scale™ Practitioner (CSaSP) an. Zielgruppe der 2-tägigen Ausbildung sind Scrum Master, Product Owner sowie Manager und Projektleiter. Wollen Sie zwei Jahre nach Zertifizierung Ihren Scrum@Scale Practitioner™ Titel behalten, so müssen Sie wiederkehrend eine Prüfung ablegen und zudem eine Erneuerungsgebühr bezahlen.

Fazit

Sie setzen Scrum bereits in unabhängigen Produktteams erfolgreich ein? Sie möchten das erprobte agile Vorgehen für eine Organisationsgröße jenseits von 100 Personen skalieren? Neben dem Large Scale Scrum (LeSS) Framework und dem Nexus™ Framework empfehlen wir Ihnen einen Blick auf Scrum at Scale zu werfen. Der Ansatz erweitert Scrum um wenige Konzepte und legt damit die Basis für eine verteilte Produktentwicklung.

Dabei ist das Anwendungsspektrum von Scrum at Scale nicht auf Ihre IT-Abteilung limitiert. Laut dem Scrum@Scale® Guide lässt sich der Rahmen auch für andere Unternehmensbereiche heranziehen. In jedem Fall empfehlen wir Scrum at Scale auf Ihr Unternehmen anzupassen, statt die Organisation in das Konzept pressen zu wollen. Gerne unterstützen wir bei Auswahl, Verprobung und Roll-out.

Leseempfehlungen

• Cobb, C.: Enterprise-level Agile Project Management – ScrumAtScale, Udemy Online Kurs, 2019
• Sutherland, J.: Scrum@Scale® Guide – The Definitive Guide to Scrum@Scale: Scaling that Works, 2019 (letzter Abruf: 31.12.2019)
• Tsielepi, R.: Scrum@Scale in under 15min, YouTube Video (letzter Abruf: 31.12.2019)

Sie wollen Ihre Entwicklungsarbeiten agil skalieren?
Gerne unterstützen wir Sie beim Ihrem Vorhaben!

Bitte akzeptieren Sie unsere Datenschutzerklärung.