Scrum im Großeinsatz – agile Skalierungsmodelle

Scrum ist im Trend. Bitkom Research veröffentlichte im September 2018 eine Studie, laut der 9 von 10 Handelsunternehmen (also 91%), die agile Methoden anwenden, auf Scrum setzen[1]. Als Gründe dafür gaben die befragten IT-Vorstände/ Abteilungsleiter und CIOs qualitativ bessere Projektergebnisse, einfachere Zusammenarbeit mit IT-Freelancern, die schnellere Umsetzung von Projekten und schnelleres Erkennen und Reagieren auf auftretende Probleme an.

Viele, die Scrum erfolgreich einsetzen, wollen aber nicht nur auf Projektebene agil sein, sondern auch im großen Rahmen auf Organisationsebene agil werden. Dazu muss man Scrum, das für selbstorganisierte Teams mit 3 – 9 Mitgliedern gedacht ist, skalieren. Also das, was im Kleinen gilt, aufs große Ganze übertragen (Upscaling).

Diesen evolutionären Weg gehen nicht alle Unternehmen heute. Einige versuchen auch, eine agile Transformation der gesamten Organisation Top-Down (Downscaling) durchzuführen. In diesem Fall braucht man Strukturen und Vorgaben, die für alle Teams projektübergreifend gelten. Einen interessanten Bericht eines solchen „Totalumbaus“ kann man beispielsweise im brand eins Artikel ING-Diba. Eine Bank auf Speed [2] lesen.

Scrum of Scrums – SoS

Scrum of Scrums war eine der ersten Methoden für agile Skalierung. Die Begründer von Scrum, Jeff Sutherland und Ken Schwaber, setzten diese Skalierungstechnik bei IDX Systems (heute GE Healthcare) von 1996-2000 auf Unternehmensebene (8 Geschäftsbereiche mit jeweils mehreren Produktlinien) ein. Die Methode regelt in erster Linie die teamübergreifende Kommunikation und überträgt die Regeln, die für einzelne Teams gelten, auf eine übergeordnete Ebene. Vertreter der einzelnen Teams treffen sich nach dem Daily Scrum, um sich über Ergebnisse auszutauschen und Hindernisse aus dem Weg zu räumen. Ein Scrum of Scrums Master leitet diese Meetings und arbeitet bei Bedarf mit einem Executive Action Team (ETA) bestehend aus Chief Product Owner und weiteren Mitgliedern der Management-Ebene (z. B. CIO, CFO, COO) zusammen. Ein richtig durchgeführtes Scrum of Scrums kann auch als Minimum Viable Release Team (= kleinstmöglich funktionierendes Freigabe-Team) für Produkte/Produktlinien verstanden werden. Scrum of Scrums dient allerdings nicht der Bearbeitung und Strukturierung des Backlogs, der Verteilung von Epics oder der Planung von Releases. Dafür gibt es heute weitere Frameworks, die größtenteils aus Best Practices entstanden sind und bis zur Programm- und Portfolio-Ebene einsetzbar sind. Scrum of Scrums ist aber in vielen dieser Frameworks enthalten.

Large Scale Scrum – LeSS

Gerade die Synchronisierung von Backlogs und die Release-Planung mit vielen Teams werfen bei der Skalierung von Scrum viele Fragen auf. Craig Larman und Bas Vodde haben dafür 2005 ein Framework namens Large Scale Scrum, kurz LeSS, entwickelt.

Die Devise des Frameworks ist: More with LeSS. LeSS setzt nicht auf zusätzliche Regeln, Prozesse, Rollen und Artefakte zu Scrum, sondern betont die Selbstorganisation der Teams und die Orientierung am Feedback von Kunden. Komplexe organisatorische Strukturen sollen aufgehoben werden, weil sie die Eigenverantwortung und den Blick für das Wesentliche in der Produktentwicklung eindämmen. Das sei nicht einfach, sondern erfordere eine Bewusstseinsänderung auf allen Ebenen (Lean Thinking). Voraussetzung für diese Denkweise sind absoluter Respekt untereinander und der gemeinsame Wille zur kontinuierlichen Verbesserung. Beides lässt sich nicht verordnen, sondern muss kollektiv erlebt werden.

Im Large Scale Scrum Modell gibt es einen übergeordneten Product Owner und ein gemeinsames Product Backlog. Nach jedem Sprint wird ein integriertes, potenziell lieferfähiges Produktinkrement bereitgestellt. Die Sprintplanung ist in zwei Stufen unterteilt: In der Sprintplanung 1 wählt jedes der parallel arbeitenden Teams Features aus dem gemeinsamen Product Backlog aus, die es implementieren will. In der Sprintplanung 2 planen die einzelnen Feature Teams, wie sie die Items aus dem Product Backlog in ihrem Sprint Backlog weiter verfeinern und umsetzen. Während des Sprints tauschen sich die Teams untereinander aus, um ein gemeinsames, integriertes Produktinkrement am Ende des Sprints liefern zu können. Innerhalb des Sprints findet ein Product Backlog Refinement statt, bei dem Feedback von Kunden eingeholt und das Backlog entsprechend angepasst wird. Nach dem Sprint erfolgt ein teamübergreifendes Review mit den Stakeholdern, um das Produktinkrement zu bewerten und anschließend evaluiert jedes Team in einer Retrospektive, wie der Sprint verlaufen ist und was verbessert werden könnte. Darauf folgt eine Overall Retrospektive (von Product Owner, Scrum Masters, Vertretern der Teams & des Managements) mit dem Ziel, die gesamte Organisation und deren Wertschöpfung zu prüfen und anzupassen (Inspect & Adapt). LeSS ist für 2 – 8 Teams (also 10 – 50 Mitarbeiter) geeignet, LeSS Huge ist für mehr als 8 Teams (50 – 6000+ Mitarbeiter).

LeSS Huge definiert zusätzlich Area Product Owner, die für sogenannte Requirement Areas im Product Backlog zuständig sind. Das sind übergeordnete, kundenorientierte Kategorien im Product Backlog. Diese Areas sorgen für eine weitere Strukturierung der Teams. Die zusätzliche Ebene bringt jedoch einige nicht triviale organisatorische Veränderungen mit sich und sollte deshalb besser schrittweise eingeführt werden.

Nexus™

Das Nexus Framework wurde von Ken Schwaber 2015 unter Scrum.org erstmals vorgestellt. Die Wahl des lateinischen Namens verdeutlicht, dass es eine Beziehung oder Verbindung zwischen Personen oder Dingen herstellen soll. Grundsätzlich gelten darin alle Regeln des Scrum Guides und auch die grafische Darstellung des Scrum-Zyklus wurde nur um Rollen, Artefakte und Events ergänzt.

Schwaber bezeichnete sein Skalierungsmodell ursprünglich als Exoskelett zu Scrum, betitelt seinen Leitfaden heute aber deutlich lockerer als „Spielregeln“. Beim Zusammenspiel mehrerer Teams (Nexus ist für 3-9 Teams geeignet, Nexus+ für bis zu 81) bestehe laut Nexus Guide[4] die besondere Herausforderung darin, Abhängigkeiten von Anforderungen, Domänenwissen sowie Software- und Test-Artefakte gemeinsam zu managen. Gesammelt wird der gesamte Input ins Nexus in einem gemeinsamen Product Backlog. Ein einziger Product Owner ist für dieses verantwortlich. Er sorgt dafür, dass der Output des Nexus wertvoll ist. Was ist nun genau die Erweiterung zu Scrum?

1. Refinement. Dieses Event findet kontinuierlich statt. Es dient der Verfeinerung von Backlog Items in implementierbare Einheiten, klärt Abhängigkeiten und soll die Zuordnung von Items zu Entwicklungsteams vorbereiten helfen. Auch innerhalb der Scrum Teams soll das Refinement während der Sprints fortgesetzt werden.
2. Nexus Sprint Planning. Dieses Event mit allen Teams dient der Koordination sämtlicher Aktivitäten im nächsten Sprint. Der Product Owner erläutert das Sprint-Ziel und bereitet das Backlog entsprechend vor. Vertreter der Teams bringen Ergebnisse Ihrer Refinements ein. Wenn die gemeinsame Sprint-Planung steht, plant jedes Team individuell weiter auf Teamebene. Das Sprint-Planning ist erst abgeschlossen, wenn alle Teams fertig sind und folgendes Artefakt erstellt ist:
3. Nexus Sprint Backlog. Darin sind alle Items der einzelnen Team Sprint Backlogs zusammengefasst. Es soll Abhängigkeiten im Sprint verdeutlichen. Deshalb wird es am besten täglich nach dem Nexus Daily Scrum aktualisiert.
4. Nexus Sprint Review. Es ersetzt die einzelnen Reviews in den Teams, ist also für alle. Das integrierte Produktinkrement wird den Stakeholdern präsentiert, die Feedback geben sollen, damit das Product Backlog für die Folgesprints entsprechend angepasst werden kann.
5. Nexus Daily Scrum. Dieses Event ist den Daily Scrums übergeordnet. Vertreter aus den einzelnen Teams treffen sich und diskutieren, ob die Integration des bisher Gebauten erfolgreich ist, welche neuen Abhängigkeiten identifiziert wurden und welche Informationen teamübergreifend geteilt werden müssen. Außerdem soll der Fortschritt in Hinblick auf das Ziel überprüft werden. Die Ergebnisse sollen in die Daily Scrums der Teams mitgenommen werden.
6. Nexus Sprint Retrospective. Dieses Event soll für die kontinuierliche Verbesserung durch Inspect and Adapt sorgen und besteht aus drei Teilen: Zuerst treffen sich Vertreter aus den Teams und adressieren Probleme, die für mehr als ein Team relevant sind, dann wird in jedem Scrum Team eine eigene Retrospektive auf Grundlage dieser Ergebnisse abgehalten und zum Schluss treffen sich wieder Vertreter aus den Teams und beschließen, wie man Maßnahmen zur Problembehebung transparent und verfolgbar für alle macht.
7. Nexus Integration Team (NIT). Die wesentlich neue Rolle. Dieses Team hat die Aufgabe, für die Integration der parallel laufenden Entwicklung in ein gemeinsames Produktinkrement mit dem Status „Done“ am Ende eines Sprints zu sorgen. Das NIT führt und berät die anderen Scrum Teams und löst technische sowie nicht-technische Probleme, die im Zusammenspiel der Teams auftreten. Mitglieder sind der Product Owner, ein Scrum Master (kann auch gleichzeitig Scrum Master in einem anderen Team sein) und Teammitglieder (die ebenfalls gleichzeitig in anderen Teams mitarbeiten können). Ist man Teil des NIT, hat die Arbeit darin aber absolute Priorität. Die Zusammensetzung des NIT darf sich ändern.

Wie Scrum ist Nexus eine frei verfügbare Methode. Schwaber weist darauf hin, dass man Nexus auch nur in Teilen anwenden kann. Das Ergebnis sei dann aber nicht Nexus.

Scrum-Puristen dürften sich hier gut aufgehoben fühlen, denn genauso wie der Scrum Guide, gibt der Nexus Guide nur eine überschaubare Anzahl an festen Regeln vor. Wie genau Nexus+ zu Nexus weiter skaliert wird, wird nicht ausgeführt. Offenbar werden die Regeln einfach auf eine weitere Nexus+ Ebene analog zu Nexus übertragen.

Scaled Agile Framework – SAFe®

SAFe® wurde 2011 von Dean Leffingwell in der Version 1.0 vorgestellt. Heute wird an Version 5.0 gearbeitet und etliche Konzerne wie z.B. Porsche, Deutsche Telekom, die U.S. Airforce oder FedEx werden offiziell als Anwender der Methode[5] gelistet. Im Vergleich zu anderen Frameworks ist dieses Skalierungsmodell deutlich schwergewichtiger und wird deshalb des Öfteren auch als „nicht-agil“ kritisiert. Nicht nur Praktiken aus Scrum, sondern auch aus Lean Production, Kanban, XP, DevOps und Design Thinking sind in dieses Modell eingeflossen. Der erste Blick auf die einfachste Grafik des Frameworks ist vergleichsweise überwältigend und nicht selbsterklärend.

www.scaledagileframework.com

Innerhalb von SAFe gibt es vier Abstufungen: Essential SAFe, Large Solution SAFe, Portfolio SAFe und Full SAFe. Mit jeder Stufe deckt das Framework komplexere und umfassendere Entwicklungen auf Team-, Programm- und Portfolioebene ab.

Auf Teamebene wird ScrumXP oder Kanban mit den üblichen Rollen praktiziert. Das Zusammenspiel der unterschiedlichen Teams wird als Programm bezeichnet und von einem Release Train Engineer, einem Systemarchitekten und einem Product Manager unterstützt. Außerdem gibt es die Rolle der Business Owners, die aktiv und kontinuierlich mit allen anderen Rollen zusammenarbeiten und dafür zuständig sind, dass der sogenannte Agile Release Train (ART) fährt und den Geschäftswert steigert. Die Mission, Vision und der Fahrplan dieses Entwicklungszuges wird im Program Increment Planning (PI) gemeinsam entworfen. Das PI liefert den Herzschlag für SAFe. Im direkten Austausch (online bei verteilten Teams) legen alle Beteiligten Ziele und Termine fest und identifizieren Abhängigkeiten. Im Anschluss daran planen die Teams ihre Iterationen. Dafür müssen Sie mit dem SAFe Requirements Model vertraut sein, um die genaue Differenzierung von Epics, Capabilities, Features, Stories, Non-Functional Requirements sowie die dazugehörigen Enabler (bzgl. zukünftigem Kundenbedarf, Architektur, Infrastruktur, Compliance) zu verstehen. Die realisierten, integrierten Features werden am Ende jeder Iteration als System Demo den Stakeholdern präsentiert. Am Ende eines Program Increments wird ein teamübergreifendes Inspect & Adapt (I&A) abgehalten, bei dem das ganze Inkrement betrachtet und bewertet wird. Außerdem gibt es am Ende jedes Program Increments eine Innovation und Planning Iteration. Das ist eine Art Puffer, der dazu genutzt werden soll, Ziele zu erreichen, Innovation voranzutreiben, Mitarbeiter zu qualifizieren oder PI und I&A vorzubereiten. Denn zu hoher Zeitdruck vernichtet Innovation.

Und wie werden die Workflows, Aktivitäten und Automation zur Bereitstellung neuer Funktionalität koordiniert? Dafür gibt es die Continuous Delivery Pipeline, durch die der Agile Release Train fährt. Sie sorgt dafür, dass auf Abruf Releases geliefert werden können. Drei Feedback-Schleifen arbeiten in der Pipeline verzahnt zusammen: Continuous Exploration, Continuous Integration und Continuous Deployment. Im Ganzen ist die Pipeline eine Lernschleife: Annahmen werden getroffen, daraufhin wird gebaut und dann das Ergebnis evaluiert. Die so gewonnenen Erkenntnisse fließen wiederum in neue Annahmen ein. Der Durchfluss durch die Pipeline lässt sich am besten an einem Program Kanban-Board ablesen.

Puh, damit haben wir nicht einmal Essential SAFe ganz umrissen. Large Solution und Portfolio SAFe setzen noch einmal ein Stockwerk mit übergeordneten Rollen, Abläufen und Wertschöpfungsindikatoren oben drauf. Beim Navigieren durch SAFe hat man wirklich das Gefühl, es wurde nichts vergessen. Im Vergleich zu den anderen Modellen ist der Interpretationsspielraum gering. Das Akronym SAFe soll bestimmt nicht ganz zufällig Sicherheit in puncto Architektur, Governance und Compliance vermitteln. Das Portfolio und das Full SAFe Modell ermöglichen es zudem, eine Vielzahl von unabhängigen Projekten zur gemeinsamen Steigerung des Geschäftswerts einer Organisation zu vereinen. In seiner methodischen Fülle überwältigt einen das vielschichtige Modell mit den zahlreichen verlinkten Definitionsseiten jedoch auch. So verwundert es nicht, dass für die Einführung von SAFe zunächst das Training sämtlicher Schlüsselrollen empfohlen wird.

Weitere agile Skalierungsframeworks wie Disciplined Agile Delivery (DAD) von Scott Ambler oder die Spotify Methode sehen wir uns gerne einmal in einem Folgeblog an.

Auch wir bei microTOOL beschäftigen uns mit agilen Skalierungsmodellen. objectiF RPM bietet eine Fülle von Features, um Abhängigkeiten von Anforderungen, Artefakte und Aktivitäten projektübergreifend mit verteilten Teams zu managen. Wie man mit unserer Software LeSS unterstützen kann, hat Ursula Meseberg in einem Blogbeitrag bereits beschrieben. Für Programmmanagement (wie es beispielsweise SAFe vorschlägt) veröffentlichen wir in Kürze ein Template. Unterstützung für das Portfoliomanagement in Kombination mit Risikomanagement werden wir im neuen Jahr in objectiF RPM anbieten.

Uns interessieren Ihre Erfahrungen mit diesen Modellen. Was haben Sie schon ausprobiert bzw. welches können Sie empfehlen? Teilen Sie Ihre Erfahrungen mit uns per Kommentar.

[1] https://www.bitkom-research.de/de/pressemitteilung/scrum-koenig-unter-den-agilen-methoden

[2] https://www.brandeins.de/magazine/brand-eins-wirtschaftsmagazin/2018/lebensmittel/ing-diba-eine-bank-auf-speed

[4] https://www.scrum.org/resources/nexus-guide

[5] https://scaledagile.com/insights-customer-stories/