Scrum@Scale – Ein echtes “Scrum of Scrums” Framework

Scrum at Scale wurde von Jeff Sutherland, einem der beiden Scrum-Gründer 2018 vorgestellt und im Scrum@Scale Guide veröffentlicht. Dabei positioniert sich Scrum@Scale als unmittelbare Alternative zu Nexus, das wiederum vom zweiten Scrum-Gründer Ken Schwaber entwickelt wurde. Und obwohl die beiden 25 Jahre Scrum vereint, sind Nexus und Scrum at Scale grundsätzlich unterschiedlich. 

Scrum@Scale setzt über alle Organisationsebenen konsequent auf Scrum. Dabei ist das Framework durch folgenden einfachen Aufbau gekennzeichnet mit einem Scrum of Scrums als zentralen Baustein. Damit kannst Du Scrum theoretisch beliebig über die folgenden Ebenen skalieren. 

1. Teams arbeiten regulär nach Scrum mit einem PO, einem Scrum Master und einer optimalen Teamgröße bis zu 5 Entwickler.
2. Ab zwei Teams synchronisiert ein Scrum of Scrums (SoS) die Arbeit der angeschlossenen Scrum-Teams, optimale Größe eines SoS sind 4 bis  5 Teams.
3. Ein Scrum of Scrum of Scrums (SoSoS) synchronisiert die Arbeit mehrerer Scrum of Scrums (SoS). 

Damit entsteht ein pyramidenförmiger Organisationsaufbau, mit Scrum of Scrums (SoS) als zentralem Konzept. Denn selbst ein SoSoS ist am Ende nur ein Meta Scrum of Scrums des darunter liegenden Scrum of Scrums. 

Das Scrum of Scrums (SoS) ist das zentrale Organisationskonzept in Scrum@Scale. Dabei übernimmt das SoS die Aufgaben des Scrum Masters und des Product Owners auf der nächst höheren Organisationsebene für alle angeschlossenen Scrum-Teams. Somit ist das SoS zuständig für die reibungslose Umsetzung des Scrum Prozesses (“How”) und die inhaltliche Ausrichtung (“What”). Um diese Ziele zu erreichen und am Ende des Sprints ein integriertes Inkrement zu liefern, hält das SoS alle Scrum-Events in einer skalierten Version ab. Zusätzlich führt Scrum@Scale die neuen Rollen Chief Product Owner (CPO) und Scrum of Scrums Master (SoSM) ein. Damit wird sichergestellt, dass auch das SoS wie ein Scrum Team arbeiten kann. Die PO relevanten Aufgaben werden über einen Product Owner Zyklus organisiert. Analog dazu gibt es einen Scrum Master Zyklus. Die beiden Zyklen haben vor allem darstellenden Charakter und geben dem Aufbau des Scrum@Scale Frameworks Struktur.

Der Scrum Master Zyklus skaliert die Arbeit eines einzelnen Scrum Masters. Das heißt, was ein Scrum Master auf Team Ebene tut, erledigt der Scrum Master Zyklus in einem Scrum of Scrums. Dabei ist der Scrum Master Zyklus auch für die Integration der Arbeitsergebnisse und die “Delivery” eines Inkrements am Ende des Sprints zuständig. Um die reibungslose Durchführung des Scrum of Scrums zu ermöglichen, wird die Rolle des Scrum of Scrums Master (SoSM) eingeführt. Zudem stellt das Executive Action Team (EAT) sicher, dass der Anschluss auch an nicht agile Organisationseinheiten erhalten bleibt und die Organisation auf ihrem Weg zur organisatorischen und prozessualen Exzellenz geführt wird.

Scrum@Scale definiert die neue Rolle eines Scrum of Scrums Masters (SoSM). Dabei fungiert der SoSM als Scrum Master für das Scrum of Scrums und sorgt für dessen effektive Umsetzung. Dazu zählt die Kommunikation innerhalb des SoS, die Offenlegung von Hindernissen, eine enge Zusammenarbeit mit dem Product Owner Team, dem CPO und laufende Prozessverbesserungen. Statt jedoch wie ein normaler Scrum Master die Qualität eines einzelnen Teams zu verbessern, richtet der SoSM seinen Augenmerk auf sein Scrum of Scrums. Die Rolle des SoSM besetzt Du entweder mit einem Scrum Master eines Teams oder mit einem dedizierten SoSM. In jedem Fall darfst Du eine so wichtige Rolle mit einer erfahrenen und gestandenen Führungspersönlichkeit besetzen. 

Mit Scrum@Scale wird außerdem das Executive Action Team (EAT) gegründet, das die agile Entwicklung der gesamten Organisation fordert und fördert. Das EAT besteht aus Führungspersönlichkeiten, die aufgrund ihrer Position grundlegende Hindernisse eliminieren und organisatorische Entscheidungen treffen können. Du kannst dir das EAT als Scrum Master Team der gesamten Organisation vorstellen, das die Arbeit eines agilen Coaches auch über die Grenzen des SoS hinaus unterstützt und vor allem als Bindeglied zu “nicht agilen” Organisationseinheiten fungiert. Das wichtigste Ziel des EAT ist die Agilität der gesamten Organisation zu fördern. Dazu pflegt das EAT ein eigenes Backlog von Initiativen, um die Qualität, Anpassungsfähigkeit und Geschwindigkeit der gesamten Organisation zu verbessern. Während es für jeden SoS einen eigenen SoSM gibt, existiert nur ein EAT für die gesamte Scrum@Scale Organisation. Für kleinere Scrum@Scale Implementierungen ist das EAT nicht erforderlich, je größer die Implementierung und vor allem der “nicht agile Teil” der Organisation, desto wichtiger. 

Der Product Owner Zyklus ist das Pendant zum Scrum Master Zyklus und skaliert im  Scrum of Scrums die Arbeit des Product Owners. Das heißt, was ein Product Owner auf Team Ebene tut, erledigt der Product Owner Zyklus auf Ebene des Scrum of Scrums. Dabei sind die Product Owner der angeschlossenen Scrum-Teams in einem “Product Owner Team” organisiert, denen die neue Rolle des Chief Product Owners vorsteht. Zusätzlich definiert Scrum@Scale das “Executive MetaScrum (EMS)” als zentrales Hub des Product Owner Zyklus, um die inhaltliche Ausrichtung des Scrum of Scrums mit den Zielen und der Strategie der gesamten Organisation zu verbinden. 

Der Chief Product Owner (CPO) ist die zweite neue Rolle in Scrum@Scale. Genau wie ein Product Owner ist der CPO in letzter Instanz für die Priorisierung und die gemeinsame Ausrichtung auf Ebene des Scrum of Scrums zuständig. Der CPO arbeitet eng mit dem Product Owner Team zusammen, in dem die Product Owner der jeweiligen Teams organisiert sind. Gemeinsam entwickeln sie die strategische Vision, entscheiden über Releases, priorisieren das Backlog und refinen anstehende Aufgaben, damit alle Scrum-Teams im SoS gemeinsame Ziele verfolgen. Mit dem CPO als dem “Product Owner der Product Owner”. Wenn es ein SoSoS gibt, gibt es entsprechend also einen Chief Chief Product Owner und alle Chief Product Owner der SoS finden sich im Product Owner Team des SoSoS wieder. 

Das Executive MetaScrum (EMS) ist ein Event, über das sich der CPO und das Product Owner Team mit Führungskräften, wichtigen Stakeholdern und Kunden vernetzen, um die Strategie und inhaltliche Ausrichtung des SoS zu besprechen. Das EMS soll mindestens einmal pro Sprint abgehalten werden. Während der CPO und die Product Owner der Teams oder ihre Vertreter feste Mitglieder des EMS sind, kann sich die Gruppe der teilnehmenden Stakeholder ändern. Dabei ist lediglich darauf zu achten, dass die richtigen Leute vertreten sind, um die Ausrichtung des Scrum of Scrums bzw. der gesamten Scrum@Scale Organisation mit den Zielen und der Strategie der gesamten Organisation effektiv zu synchronisieren. Dabei gibt es immer nur ein EMS für die gesamte Scrum@Scale Organisation, je nach Aufbau der Scrum at Scale Organisation noch untergeordnete MetaScrums (MS) auf Ebene der SoS. 

Auf Ebene des SoS werden alle Scrum-Events in einer skalierten Version abgehalten. Unberührt davon sind die Scrum-Events auf Ebene der jeweiligen Teams, das heißt die skalierten Events werden zusätzlich zu den Scrum Events auf Teamebene abgehalten.

Die skalierte Version des Sprint Plannings wird vom Chief Product Owner (CPO), verantwortet. Teilnehmer sind außerdem das Product Owner Team und die Scrum Master. In der skalierten Version des Plannings werden die Aufgaben für den Sprint festgelegt, die die Product Owner dann in ihr Team Planning mitnehmen.

Die skalierte Version des Daily findet täglich für 15 Minuten statt. Dabei stellt der Scrum of Scrums Master (SoSM) sicher, dass dieses Event stattfindet, produktiv ist und innerhalb der time-box gehalten wird. Aus jedem Scrum Team des Scrum of Scrums nimmt mindestens ein Repräsentant teil.

Die skalierte Sprint Review wird vom  Product Owner Team, angeführt durch den Chief Product Owner (CPO), verantwortet. Hierbei wird das integrierte Inkrement durch die beteiligten Mitglieder und Stakeholder begutachtet.

Zum Ende des Sprints wird eine skalierte Version der Retrospektive durch den Scrum of Scrums Master (SoSM) abgehalten. Daran nehmen jedoch nicht die Teammitglieder, sondern die Scrum Master aller Teams des SoS teil.

Für das skalierte Backlog Refinement treffen sich das Product Owner Team und der Chief Product Owner (CPO). Ziel des Refinements auf Ebene des Scrum of Scrums ist die Product Backlog Items in kleinere Einheiten zu zerlegen (Decomposing), um sie in den Team-Refinements weiter zu verfeinern und zu planen. Das heißt, im skalierten Refinement geht es anders als auf Teamebene darum, große Anforderungen in kleinere zu zerlegen. Damit diese zerlegten Product Backlog Items überhaupt in den Sprint einfließen können.

Scrum@Scale versteht sich als ein modularer Baukasten, dessen Komponenten Du beliebig auch auf deine Organisation anpassen kannst. Die folgenden Beispiele und Case Studies helfen dir die bis hierhin vorgestellten Konzepte miteinander zu verknüpfen.  

Wenn Du beabsichtigst Scrum of Scrums in der Organisation zu implementieren, dann schlägt Scrum@Scale den Weg über einen Prototypen bzw. ein Referenzmodell vor. Das Referenzmodell beinhaltet zunächst eine kleine Anzahl von Scrum-Teams, die gemeinsam an einem Produkt arbeiten und in einem Sprint ein integriertes Inkrement schaffen. Das heißt, Du gründest dein erstes Scrum of Scrums, etablierst einen CPO, ernennst den Scrum of Scrums Master (SoSM). Im Anschluss richtest Du das Executive MetaScrum als Format ein, gründest das Executive Action Team und hältst alle Events auch in einer skalierten Version ab. Natürlich ist es von Vorteil, wenn die Teams bereits in einem Scrum-Setup arbeiten, sonst solltest Du auf Teamebene anfangen und dort zunächst Scrum etablieren. 

Mit dem ersten Beispiel einer möglichen Scrum@Scale Implementierung wird der modulare Aufbau des Frameworks ersichtlich. Auch wenn der rote Faden des Scrum of Scrums erhalten bleibt, hat jedes SoS eine unterschiedliche Anzahl von Teams. Zudem gibt es für jedes Scrum of Scrums ein MetaScrum und ergänzend zusätzlich ein Executive MetaScrum (EMS).

Im zweiten Beispiel stehen das EAT und EMS im Zentrum der Scrum@Scale Organisation. In drei SoSoS werden insgesamt 10 Scrum of Scrums organisiert, auf Ebene des SoSoS wird ein MetaScrum der jeweiligen Chief Product Owner der SoS abgehalten. Da Scrum konsequent skaliert wird, gibt es auf Ebene des SoSoS einen Chief Chief PO. Zusätzlich hält jedes Scrum of Scrums ein MetaScrum der jeweiligen PO ab, denen ja wiederum der CPO des jeweiligen Scrum of Scrums vorsteht. In Summe werden so über drei SoS, zehn Scrum of Scrums und insgesamt 38 Scrum-Teams synchronisiert. 

In einem sehr kurzen und sehenswerten Video erzählt Henrik Kniberg, wie die Entwicklung des Spotify Modells das Scrum@Scale Framework beeinflusst hat. 

• Executive MetaScrum = Strategy Days bei Spotify
• Executive Action Team = POTLAC der Spotify Tribes (POTLAC = Product Owner (PO) + Team Lead (TL) + Agile Coach (AC))
• Fokus on Delivery, “ship fast” = Delivery Fokus im Scrum Master Zyklus

Die letzte Case Study startet mit zwei wichtigen Key Learnings der agilen Transformation bei Bosch. Erstens, dass eine duale Organisation für Bosch nicht funktioniert hat. Also die Idee, dass ein Teil des Unternehmens in traditionellen Strukturen das “business as usual” erledigt und andere Organisationseinheiten Innovationen in agilen Strukturen vorantreiben. Das zweite Learning bezieht sich auf den Versuch Agilität über ein klassisches Wasserfall-Projekt einzuführen. Da auch dieses Vorgehen erfolglos war und da der Flaschenhals immer am Kopf der Flasche sitzt, hat sich schließlich der Lenkungsausschuss als ein “Scrum of Scrums” organisiert.  Das heißt, satt schlauer Ratschläge haben sie sich die Hände schmutzig gemacht und ihre angeschlossenen Teams aktiv supportet. Statt jährlicher Budgetierung hin zu kontinuierlicher Priorisierung und Budgetierung.

Scrum@Scale ist ein echtes “Scrum of Scrums” Framework und skaliert Scrum sehr konsequent über mehrere Ebenen. Ein Aspekt, den ich an Scrum@Scale gerne mag, ist das Enterprise Action Team (EAT), das als agiler Enterprise-Coach auftritt. Zudem mag ich den modularen Aufbau, der eine gewisse Flexibilität ermöglicht. Insgesamt ist Scrum@Scale im Vergleich zu LeSS oder SAFe deutlich leichtgewichtiger, jedoch auch deutlich umfangreicher als Nexus. Was mich jedoch offen gesagt etwas irritiert, dass scheinbar nicht einmal die beiden Scrum Väter Einigkeit darüber haben, wie Scrum erfolgreich skaliert werden kann und mit Nexus und Scrum@Scale zwei alternative Konzepte propagiert werden. Ein Grund mehr auch Scrum@Scale nur als eine “Inspiration” und einen möglichen Startpunkt für die Entwicklung deiner agilen Organisation zu verstehen. Und die (An)Passung schließlich in die Hände deiner Mitarbeiter und eines konsequenten agilen Prozesses zu legen. Dabei gilt in meinen Augen eine sehr einfache Regel: Erst auf Teamebene festigen und Exzellenz entwickeln, dann skalieren. 

Viel Erfolg dabei.