Scrum@ScaleTM – Neues Scrum-Skalierungsframework von Dr. Jeff Sutherland & Scruminc.com
Scrum als agiles Entwicklungsframework für Produkte (Hardware, Software), Prozesse, Services und komplexe integrierte Systeme ist zwischenzeitlich etabliert. Teams mit maximal 9 Entwicklern wie in Scrum Guide beschrieben, sind für viele Produktentwicklungsszenarien jedoch häufig nicht mehr ausreichend.
Agile Frameworks die skalieren, d.h. auf viele Entwickler und viele Teams praktikabel anwendbar sind um umfangreiche und integrierte Produktentwicklungen zu unterstützen, werden gebraucht. Zwischenzeitlich haben sich viele Frameworks auf Basis von Scrum und anderer agiler Methoden entwickelt, die eine solche Skalierung leisten.
Die bekanntesten unter anderem sind das SAFe – Scaled agile Framework, LeSS – Large Scale Scrum, NEXUS, Spotify etc.. Diese Skalierungsarchitekturen haben ihre Anwendungsfelder und sind unterschiedlich komplex in der Umsetzung und Anwendung.
Ein neues, weiteres Modell wurde am 10.2.2018 von Dr. Jeff Sutherland, der Co-Founder von Scrum, und Mitarbeitern seiner Firma Scruminc.com im Rahmen eines Guides vorgestellt: The Scrum@ScaleTM-Guide 1.0
Zweck und Hintergrund des Guides
Mit Hilfe einer „minimal viable bureaucracy“, frei übersetzt als „minimal machbare Bürokratie“ (oder mit geringstmöglicher Bürokratie) sollen dabei die Prinzipien, die einem Single Scrum Team und den Scrum Vorgehensweisen zugrunde liegen, über die ganze Organisation, über alle Abteilungen, Produkte und Services hinweg erweitert werden können.
Und das ohne eine spezielle Skalierungs-Architektur mit beliebigen Regeln sondern ausschließlich durch organisches Wachstum, basierend auf dem akzeptierten Veränderungstempo in der Organisation und dem bekannten Scrum Framework. So können die Aufwände für die agile Transformation in denjenigen Bereichen mit den größten Werterwartungen oder den größten Bedarf an Veränderung begonnen werden und dann schrittweise ausgeweitet werden.
Der „The Scrum@ScaleTM-Guide 1.0 ist wie bereits vom Scrum Guide her gewohnt, mit 18 Seiten recht knapp gefasst. Ziel des Guides ist es, den Leser in die Lage zu versetzen dieses Framework selbstständig zu implementieren.
Starten mit Scrum@ScaleTM
Zunächst gilt es in der Organisation eine kleine Anzahl von Scrum-Teams aufzubauen, die in der Lage sind Scrum gut umsetzen zu können. Der Scrum@Scale<sup< a="">>TM Guide spricht hier von einem Referenzmodell, das aufgebaut werden soll. Durch weiteres organisches Wachstum soll dann eine lineare Skalierung der Produktivität durch weitere Scrum Teams erreicht werden.</sup<>
Die Komponenten
Scrum@Scale trennt auch wie im Scrum Guide dargestellt, das „Was“ von dem „Wie“, also die Abläufe aus dem Product Onwer Bereich von denen der Abläufe für das Scrum-Vorgehen. Beide Abläufe oder Zyklen berühren sich an zwei Punkten.
Abbildung Komponenten des des Fameworks; Quelle: The Scrum@ScaleTM-Guide 1.0
Der Team-Level Prozess ist im Scrum Guide ausführlich beschrieben.
Scrum Master Cycle – Koordination multipler Teams – Das “Wie”
Ein Set von Scrum Teams, die sich untereinander koordinieren müssen um ein „fully integrated set of shippable increments“ zu liefern, bilden ein Scrum-of-Scrums SoS Set.
Abbildung: Scrum-of-Scrum mit 5 Teams
Skalierung der Scrum of Scrums
Eine skalierte Variante mit 25 Teams formieren ein Scrum-of-Scrum-of-Scrums SoSoS Set
Abbildung: Scrum-of-Scrum mit 25 Teams
Laut Scrum@ScaleTM Guide lassen sich nach diesem Muster beliebig große Skalierungen erreichen.
Interessant in diesem Zusammenhang ist dort die Aussage, dass nach neueren Untersuchungen, durchgeführt von Harvard Research, die optimale Einzel-Teamgröße bei 4,6 also bei 4 bis 5 Personen liegt. Der Scrum Guide führt hier eine maximal Personenzahl von 3 bis 9 Personen auf.
Neu eingeführte Rollen im Scrum Master Cycle
Scrum-of-Scrums Master
Im Scrum@ScaleTM Guide ist die Rede von einer neue Rolle, dem Scrum-of-Scrums Master SoSM. Neben den aus dem Scrum Guide bekannten Aufgaben des Scrum Master kommen hier hinzu:</sup<>
- Priorisierung der Impediments (Hindernisse) unter besonderer Berücksichtigung der übergreifenden Team-Abhängigkeiten und der der Verteilung des Backlogs
- Optimierung der Wirksamkeit der Scrum-of-Scrums
- Enge Zusammenarbeit mit den Product ownern
- Koordination der Teameinsätze in Bezug auf den Release Plan des Product owners.
Das Executive Action Team
Scrum-of-Scrums der gesamten agilen Organisation wird im Scrum@Scale<sup< a="">>TM Guide als Executive Action Team definiert. Seine Funktion liegt in der Koordination der SoS bzw. SoSoS. Es setzt sich zusammen aus einem Product Owner und einem Scrum Master.</sup<>
Seine Rolle im Rahmen der agilen Organisationsentwicklung ist die Erstellung eines „Organizational Transformation Backlog“, eine priorisierte Liste agiler Initiativen, die umgesetzt werden müssen. So müssen beispielsweise tradierte Project-/Produktentwicklungs-Life Cycle aus der alten Organisation in neue agile Produktentwicklungs-Life-Cycle umgesetzt und nachhaltig unterstützt werden.
Das EAT ist für die Qualität von Scrum in der Organisation verantwortlich.
Abbildung EAT - Executive Action Team das 5 Gruppen mit jeweils 25 Teams koordiniert
Darüber hinaus sind die Verantwortlichkeiten des EAT unter anderem:
- Entwicklung eines agilen operationalen Systems mit operationalen Regeln, Prozessen und Leitfäden um Agilität in der Organisation zu ermöglichen und zu fördern
- Messen und Verbessern der Qualität von Scrum in der Organisation
- Fähigkeiten und Können bezüglich „business agility“ in der Organisation entwickeln
- Aufbau eines Centers für das kontinuierliche Lernen für Scrum Professionals
- Neue Wege der Arbeit erkunden und unterstützen
Schlussendlich muss das EAT eine Product owner Organisation mit Product ownern aufsetzen, die vergleichbar mit der SoS ihre Funktionen skalieren. Im Scrum@Scale<sup< a="">>TM Guide wird von „Teams of Product ownern” und “Key stakeholders” gesprochen die als MetaScrums benannt sind.</sup<>
Product Owner Cycle – Koordination multipler Teams – Das “Was” – MetaScrum
Hinter dem Begriff MetaScrum verbirgt sich eine Gruppe von Product Ownern (PO), die einen Backlog zur Versorgung der SoS koordiniert. Es gibt für jeden SoS einen MetaScrum
Abbildung Meta Scrum von 5 Teams
Die Hauptfunktionen des MetaScrum sind:
- Erstellung einer übergreifenden Vision vom Produkt und deren Bekanntmachung in der Organisation
- Abgleich mit den key stakeholder zur Absicherung der backlog Implementierung
- Erarbeitung eines single backlogs; Sicherstellung der Vermeidung von Doppelarbeiten
- Erstellung einer einheitlichen „Definition of Done1“, die für alle SoS gilt
- Eliminierung von Abhängigkeiten, die von den SoS vorgebracht werden
- Erstellung eines koordinierten Release Plans
- Entscheiden über Metriken, die zu monitoren sind, um Einsichten über das Produkt erlauben
Skalierung der MetaScrums
Nach dem gleichen Mechanismus wie die SoS zu SoSoS skalieren, expandieren die MetaScrums.
Abbildung Meta Scrum von 25 Teams
Neue Rollen im Product Owner Cycle
Chief Product Owner
Genauso wie die SoS, funktionieren MetaScrums selbständig. Ebenso, wie die SoS, die einen Scrum-of-Scrums Master haben, brauchen MetaScrums jemanden der verantwortlich die Erstellung eines einzigen Product Backlogs für alle Teams koordiniert.
Diese Person nimmt die Rolle des Chief Product Owners - CPO wahr.
Seine Aufgaben sind u.a.
- Erarbeiten einer strategischen Vision für das gesamte Produkt
- Erstellung eines einzelnen, priorisierten, wertorientierten Backlogs
- Enge Zusammenarbeit mit dem zugehörigen SoSM, um den vom MetaScrum erstellten Release-Plan effizient umsetzen zu können
- Monitoring von Kundenfeedback und entsprechende Anpassung im Backlog
Das Executive Meta Scrum
Die MetaScrums ermöglichen ein Netzwerk von Product Ownern das in Kongruenz seiner assoziierten SoS unendlich skalierbar ist.
Das MetaScrum für die gesamte Organisation ist das „Executive MetaScrum – EMS“. Das EMS setzt die strategischen Prioritäten für das gesamte Unternehmen und richtet alle Teams auf gemeinsame Ziele aus.
Metriken und Transparenz
Transparenz ist essenziell für das richtige funktionieren von Scrum. Diese Transparenz kann nur entstehen wenn die Grundwerte von Scrum angenommen und gelebt werden. Dies versetzt Organisationen in die Lage ehrlich und aufrichtig den Fortschritt zu beurteilen sowie die Untersuchung und Anpassung ihrer Produkte und Prozesse vorzunehmen.
Beide vorgestellte Zyklen, der Scrum Master Cycle und der Product Owner Cycle brauchen Metriken, die von jeweiligen SM und PO Organisationen unabhängig und organisationsspezifisch festzulegen sind.
Der Scrum@Scale<sup< a="">>TM Guide schlägt hier als Minimalausstattung für die Metrics folgendes vor:</sup<>
- Produktivität – z.B. Veränderungsrate in der Produktausbringung per Sprint
- Value delivery – z.B. Geschäftswertgenerierung pro Einheit Team-Aufwand
- Qualität – z.B. Fehlerrate oder Zeiten von Servicestillständen
- Nachhaltigkeit – z.B. Team happiness
Fazit
Der Scrum@ScaleTM Guide V 1.0 ist mit insgesamt 18 Seiten für ein solches komplexeres Thema recht knapp beschrieben. Das war aber auch bereits schon beim Scrum GuideTM so. Die Praxis hat dort die vielen offen Fragen mit konkreten Methoden und Vorgehensweisen beantwortet.</sup<>
Gut gefällt mir am Scrum@Scale die Idee und das Modell des organischen Wachstums. Damit lassen sich Skalierungen an die unterschiedlich akzeptierten Veränderungsgeschwindigkeiten einer Organisation und seiner Menschen adaptieren.
Auffällig ist offensichtlich der Bedarf an skalierbaren Modellen für Scrum. Scrum.org, vertreten durch Ken Schwaber bietet hierfür das Nexus-Framework an und Scruminc.com, vertreten durch Jeff Sutherland nun das Scrum@Scale-Framework. Hinzu kommen weitere Frameworks wie das SAFe, LeSS und weitere. Das bietet Unternehmen größere Flexibilität, macht aber die Auswahl und Entscheidung für das passende Framework aufwändiger.
Interessante Links und Hinweise
Scrum@ScaleTM-Guide ,©2006-2018 Jeff Sutherland and Scrum Inc, Released under Creative Commons 4.0 Attribution - Sharealike License
Kurzvideo zu Scrum@ScaleTM von Dr. Jeff Sutherland Scrum@scale https://youtu.be/k02ci923Po4
Der Scrum GuideTM (Deutsche Ausgabe als pdf), 2017
1 Siehe Scrum Guide