Neben Produktmanagement ist eines meiner Lieblingsthemen die agile Skalierung. Denn wie sollte man sonst umfangreichere Produkte auf die Beine stellen können? Zu agiler Skalierung habe ich bereits ein paar Artikel verfasst.
Bei all den Skalierungsframeworks gibt es Eines, dass meiner Meinung nach zu wenig Aufmerksamkeit bekommt: Scrum of Scrums.
Scrum of Scrums
Spannend ist, dass die Skalierung von Scrum von Anfang an ein Thema war …
Scrum wurde zum ersten Mal auf der OOPSLA-Konferenz im Jahr 1995 vorgestellt. Bereits Mitte der 1990er Jahre wurde Scrum of Scrums von Jeff Sutherland und Ken Schwaber entwickelt. Einen spannenden Artikel, in dem Scrum of Scrums das erste Mal (im Jahr 2001) öffentlich erwähnt wurde, findet ihr bei ResearchGate.
Übrigens, der Scrum Guide wurde zum ersten Mal im Jahr 2010veröffentlicht.
Im Laufe der Zeit hat sich – völlig zu Recht – das geflügelte Sprichwort ergeben: „If you can’t scrum, you can’t scale.“ Hintergrund ist, dass man das agile Vorgehen zunächst sicher im kleinen Rahmen beherrschen sollte bevor man skaliert. Dieses Learning begleitet die agile Community von Anfang an.
Verbreitung
Gemäß des State of Agile Report aus dem Jahr 2020 lag die Verbreitung von Scrum of Scrums bei 16 Prozent. Im aktuellen Report (Seite 16) jedoch nur noch bei neun Prozent.
Besonders erwähnenswert ist die große Angabe von ,andere/weiß nicht‘. Es kann angenommen werden, dass es sich dabei um Eigenentwicklungen, Mischungen der Frameworks oder um Unwissenheit handelt. In der Studie wird darauf leider nicht eingegangen.
Fakt ist: Die Nutzung und Einführung von Scrum of Scrums ist intuitiv und sehr einfach. Ich finde, es ist das einfachste Mittel. Denn Scrum of Scrums (SoS) hat nur minimale Auswirkungen auf bestehende Artefakte, Rollen und Events.
Ein Überblick
Das Scrum of Scrums ist eher ein Mechanismus als ein Framework. Es erweitert Scrum um ein zusätzliches Meeting, um Abhängigkeiten, Informationsflüsse sowie Synchronisations-, Koordinations- und Integrationsprobleme über mehrere Teams hinweg zu bewältigen.
Pro Team wird ein geeigneter Repräsentant (Ambassador genannt) entsandt, der im Zeitverlauf wechseln kann. Das ist wichtig, denn je nach Situation kann sich die Anforderung (Entwickler, PO, SM) an das Kompetenzprofil des Repräsentanten ändern, um bestmöglichen Austausch und Entscheidungen zu gewährleisten.
Die Frequenz des Meetings ist nicht vorgegeben und kann je nach Bedarf zwischen täglich oder zweimal pro Woche variieren. Die Dauer des Meetings beträgt 15 Minuten und sollte direkt nach den Dailies der Teams terminiert sein. Identifizierte Herausforderungen werden anschließend separat geklärt.
Es wird empfohlen, ein SoS-Backlog zu erstellen, in dem die abhängigkeits- und integrationsbezogenen Aufgaben transparent verfolgt werden können. Das SoS wird verwendet, um die Arbeit von fünf bis neun Scrum-Teams zu integrieren; für jedes weitere Produkt (oder Produktbestandteil) kann ein weiterer SoS initiiert werden.
Dies könnt ihr beispielsweise der folgenden Abbildung entnehmen. Hier werden 25 Teams dargestellt (Product Owner und Scrum Master sind als kleine, graue Pentagons symbolisiert), sodass aus einem SoS ein ,Scrum of Scrums of Scrums‘ (SoSoS) wird.
Es handelt sich hierbei um horizontale Skalierung. Denn es wird eine große Anzahl agiler Teams koordiniert, um ein done increment zu realisieren.
Herausforderungen bei Scrum of Scrums
Nachdem ich Scrum of Scrums so positiv beleuchtet habe, möchte ich auch noch auf die Herausforderungen eingehen.
Scrum of Scrums ist eine Gruppe, welche sich aus Vertretern der ursprünglichen Teams zusammensetzt. Durch verknüpfte Teamstrukturen werden Kommunikationswege drastisch verkürzt und dezentrale Entscheidungsfindung ermöglicht. Deshalb sollte die Unternehmensorganisation akzeptieren, dass die Ablauforganisation im Vordergrund steht und nicht die Aufbauorganisation. Projektleiter, Sponsoren/Business Reps, Head ofs sollten informiert und aufgeklärt werden. Ihr wisst was passiert, wenn das nicht der Fall ist …
Nächter Punkt, der in der Realität häufig verschludert wird: Informationen werden nur nach oben aggregiert, aber nicht mehr nach unten zurückgespielt. Das SoS hat sich getroffen und entschieden – diese Informationen müssen in die einzelnen Teams zurückfließen und ggf. auch dokumentiert werden. Insbesondere ein Logbuch von Entscheidungen und Absprachen ist empfehlenswert. Hierfür kann auch ein übergeordneter Slack-Channel pro SoS genutzt werden. Weiterhin können übergreifende Themen, welche das gemeinsame Ziel positiv (Service Level Agreements, Tage bis zum Release) oder negativ (Impediments, Abhängigkeiten, Risiken) beeinflussen, visualisiert werden.
Dritter Punkt: Die richtige Frequenz. Haltet auf keinen Fall stur an einer festdefinierten Frequenz fest. Diese ist abhängig von der Arbeit, die ihr bewältigt. Manchmal ist eine tägliche Frequenz über einen längeren Zeitraum sinnvoll, manchmal reicht ein Austausch zweimal wöchentlich.
Vierter Punkt: Working Agreement & Definition of Done. Überall in der Software-Entwicklung treffen Menschen mit verschiedenen Ideen, Vorstellungen und Annahmen aufeinander. All diese impliziten Punkte können uns ins Straucheln bringen. Die Explikation und das Festhalten von Working Agreements eines SoS (oder SoSoS) und auch gemeinschaftliche Diskussion von DoDs hilft, Klarheit zu schaffen. Mit gemeinsamen Spielregeln und abgeglichenen Erwartungshaltungen geht es einfach leichter. Diese können sich auch erst im Laufe der Zeit herauskristallisieren. Das bringt mich nahtlos zu Punkt fünf …
Fünfter Punkt: Verbesserung. Eigentlich geht es nur um ein Meeting nach dem Dailies der Teams? Ja! Oder doch nicht? Agilität löst keine Probleme, es macht sie gnadenlos sichtbar. Deshalb gilt der Leitsatz: Inspect & Adapt. Nutzt diesen Schritt, um auch weitere Verbesserungen im SoS (oder SoSoS) und in der Durchführung des Meetings zu generieren. Denkt vielleicht weiter und ergänzt auch eine gemeinsame Retro.
Scrum of Scrum on Steroids
Noch ein kleiner Ausflug: Scrum of Scrums ist die Grundlage des Skalierungs-Frameworks Scrum@Scale, das im Jahr 2018 veröffentlicht wurde. Jeff Sutherland definiert Scrum@Scale folgendermaßen:
Scrum@Scale is a lightweight organizational framework in which a network of teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value.
Scrum@Scale bietet einen linear skalierenden Ansatz zur Installation und Koordination mehrerer Scrum Teams, mit dem Ziel, eine hohe Qualität und einen Wert zu liefern sowie gleichzeitig die Unternehmens-Agilität zu verbessern. Dabei verknüpft es horizontale und vertikale Skalierung.
Scrum@Scale beinhaltet den Scrum Master Cycle (,Wie‘) und den Product Owner Cycle (,Was‘), die sich an zwei Punkten schneiden und so einen dritten Cycle (in der Mitte) ergeben. Scrum@Scale nutzt zwei Teams, die die Steuerung und Koordination stützen, das Executive Action Team (Scrum Master Cycle) und das Executive MetaScrum (Product Owner Cycle).
Die Skalierung auf Team-Ebene baut auf SoS auf und skaliert die Scrum Master und Product Owner pro SoS. Pro SoS sollten idealerweise fünf Teams enthalten sein, damit die Kommunikation und Koordination bewältigt werden kann. Denn nach Untersuchungen von Hackman und Vidmar, auf die sich Scrum@Scale bezieht, besteht das „perfekte Team“ theoretisch aus 4,6 Personen. Denn zu kleine als auch zu große Teams können mit der Bewältigung komplexer Probleme überfordert sein. Hier unterscheidet sich also die Anzahl der Teams von anderen Quellen (siehe oben).
Es bestehen zahlreiche Optionen, wie die Gesamtorganisation mit Scrum@Scale gestaltet werden kann. Diese Muster erlauben es, komplexe Produkte oder mehrere Produkte zu orchestrieren. Hier noch ein Beispiel aus dem Scrum@Sclae Guide:
Skalierung von Beginn an mitgedacht
Die Skalierung von Scrum ist bereits seit Beginn an ein Thema gewesen – und wie ihr seht, handelt es sich um eine einfache Mechanik, mit der man viel erreichen kann. Man muss also nicht gleich zu mächtigen Frameworks greifen, sondern es lassen sich auch mit kleinen, bedachten Anpassungen erste Erfolge erzielen.
Wenn ihr also skalieren müsst und euch Scrum of Scrums hilfreich erscheint, freue ich mich über Feedback, wie es bei euch funktioniert hat. Auch bereits gesammelte Erfahrungen interessieren mich brennend!
Quellen
- The Scrum@Scale Guide, 2021
- Rupp, C., Scaling Scrum Across Modern Enterprises, 2020, S. 241-250.
Schreibe einen Kommentar