Frameworks zur Skalierung von agilen Methoden

SAFe®

Entwickelt von Dean Leffingwell, liegt das Scaled Agile Framework (SAFe®) in mehreren Konfigurationen vor. Es setzt auf drei Ebenen an: Team, Portfolio, Programm. Die Vollversion Full SAFe® ist überdies auf den Einsatz im ganzen Unternehmen ausgelegt.

SAFe® fasst interdisziplinäre Teams, die mit Scrum oder Kanban arbeiten, zu sogenannten Agile-Release-Trains (ART) zusammen, die das Produkt inkrementell ausliefern. Auf der Programmebene werden die aus Scrum bekannten Muster skaliert. Auch hier sind drei Rollen vorgesehen: Programmmanager, Release-Train-Engineer, Systemarchitekt. Das vom ART über mehrere Sprints entwickelte Funktionspaket wird Programminkrement genannt. Geplant wird es mit allen Teammitgliedern. Dabei klären die Teams auch ihre Abhängigkeit voneinander und halten diese auf der Programmtafel fest. Unter den hier vorgestellten Skalierungsframeworks sieht nur SAFe® einen Iterationslauf vor, der nicht zur Produktentwicklung dient, sondern primär als Ideenschmiede und zum Bugfixing. Er beschließt die Arbeit an einem Programminkrement. Nach jedem Sprint besprechen alle Mitwirkenden dessen Verlauf und Resultat. Auf Portfolioebene hilft unter anderem eine Schautafel, hier Canvas (Leinwand) genannt, bei der Priorisierung der Anforderungen (Epics), die jeweils ein ART zu erfüllen hat.

Die Stärke von SAFe® liegt in der Vielzahl der schlanken und agilen Methoden, die Unternehmen von der Strategiebildung bis zur taktischen Sprintplanung unterstützen. Im Vergleich mit LeSS und Nexus, deren methodischen Minimalismus der Anwender in Eigenleistung ergänzen muss, ist das Angebot bei SAFe® überreichlich. Hier sollte man vor der Implementierung aussortieren. Sonst riskiert man einen methodischen Overkill, bei dem das eigentliche Ziel aus dem Blick gerät: der Nutzen für den Kunden.

LeSS

Large-Scale Scrum, kurioserweise abgekürzt als LeSS (weniger), wurde von Craig Larman und Bas Vodde entwickelt. Es skaliert den Scrum-Ansatz auf bis zu acht Teams, die am selben Produkt arbeiten. Jedes Team verantwortet einen Teil der Produktmerkmale, die Fähigkeiten seiner Mitglieder sollten sich ergänzen. Das Besondere an LeSS (und Nexus, siehe unten) ist, dass ein einzelner Product-Owner alle Teams fachlich anleitet. Es gibt auch nur ein gemeinsames Product-Backlog, eine gemeinsame Sprintplanung, gemeinsame Reviews und Retrospektiven. Statt sich im eigenen Ressort zu isolieren, sollen sich die Teams für das gesamte Produkt verantwortlich fühlen. Projekte, die mehr als acht Entwicklerteams erfordern, lassen sich mit der erweiterten Variante LeSS Huge stemmen. Hier arbeiten dem Produkteigner mehrere Area-Product-Owner zu, die ihrerseits mehrere Teams betreuen.

Dank flacher Hierarchie sind bei LeSS die Entscheidungswege kurz. Allerdings setzt das Modell bei Führungs- und Fachkräften bereits eine hohe Agilität voraus. Die Stärke von LeSS liegt vor allem in der Möglichkeit, durch Bildung weiterer Teams organisch zu wachsen. Das Repertoire an Methoden, die Interdependenz im Griff zu behalten, ist karg. Hilfe beim Portfoliomanagement oder bei der Strategieentwicklung sucht man vergebens. Dies mag manches Unternehmen als Freiraum zur Anpassung an eigene Strukturen und Prozesse begrüßen. Es verlangt dem Anwender aber auch Experimentierfreude ab.

Nexus

Nexus heißt das von Ken Schwaber (scrum.org) entwickelte Framework zur Entwicklung einzelner Produkte. Wie bei LeSS leitet auch hier der Product-Owner jeweils drei bis neun Scrum-Teams und führt ein gemeinsames Backlog. Charakteristisch für Nexus ist der Fokus auf stetiger Integration. Dazu wird das klassische Scrum-Arsenal um Rollen, Events und Artefakte erweitert. So sieht das Framework ein Integrationsteam (Nexus integration team, NIT) vor, bestehend aus dem Product-Owner, einem Scrum-Master sowie Vertretern der Teams. Das NIT analysiert Integrationshürden, berät die Entwickler bei der Wahl und beim Einsatz der Integrationstechniken. Anders als bei Scrum@Scale passt sich die Besetzung des NIT dem zu lösenden Integrationsproblem an. Zudem führt Nexus Koordinationsmeetings ein, in denen Teamvertreter Abhängigkeiten klären und Integrationshindernisse beseitigen. In einer Rückschau werden sonstige Probleme gelöst, die mehrere Teams betreffen.

Obwohl Nexus Scrum erweitert, bleibt das Framework ein Leichtgewicht. Unter anderem fehlen Methoden zum Portfoliomanagement und zur Strategieplanung.

Scrum@Scale

Anders als die oben genannten Frameworks skaliert Jeff Sutherlands Scrum@Scale das agile Arbeiten nicht durch feste Ebenen oder Strukturen, sondern durch lose Vernetzung der Teams sowie Trennung der Zuständigkeit für die Produktmerkmale von der Verantwortung für die Methode. Projekte beginnen mit einem einzelnen Team aus Produkteigner, Scrum-Master und Entwicklern. Hat sich dieses Team eingearbeitet, werden weitere formiert und von einer übergeordneten Instanz, dem Scrum of Scrums (SoS), koordiniert. Product-Owner und Scrum-Master bilden später jeweils eigene Teams. Über ein gemeinsames Backlog priorisiert und koordiniert das SoS der Produkteigner die Arbeit der Scrum-Teams. Ein Chief-Product-Owner übernimmt die Gesamtverantwortung und stimmt sich mit den anderen Produkteignern ab. Das SoS der Scrum-Master hingegen überwacht den Fortschritt, verantwortet die stetige Lieferung, ergreift Maßnahmen zur Steigerung der Effizienz. Auf Führungsebene werden ebenfalls zwei Teams formiert, die auf die strategische Ausrichtung des agilen Arbeitens achten und dieses im gesamten Unternehmen fördern.

Zu den Stärken von Scrum@Scale gehört die organische, unbegrenzte Skalierbarkeit. Zudem findet der Anwender Hinweise auf geeignete Metriken. Kehrseite der beliebigen Skalierbarkeit ist der fehlende Anreiz, flachere Hierarchien zu schaffen, in denen die Scrum-Teams mehr selbst entscheiden.

Spotify-Engineering-Culture

2012 beschrieben Henrik Kniberg und Anders Ivarsson, wie der Streamingdienst Spotify mit seinem rasanten Wachstum organisatorisch Schritt hält und wie ein spezifischer Arbeitsstil, die Spotify-Engineering- Culture, zur Agilität des Unternehmens beiträgt. Oft wird dieser Ansatz auf die Aufbauorganisation reduziert und als „Spotify-Modell“ tituliert. Dabei ist sie nur ein Aspekt unter vielen, die bei der Skalierung relevant sind. Den Kern bilden zwei Dimensionen der Organisation, Autonomie und Ausrichtung, sowie interdisziplinäre Teams, Squads genannt. Als interne „Startups“ agieren sie autonom und liefern inkrementell. Technisch unterstützt wird diese Arbeitsweise durch eine serviceorientierte Architektur und automatisierte Testläufe. So hat jeder Mitarbeiter die Möglichkeit, Code auszurollen. Zudem ist den Teams freigestellt, sich über ein externes Framework zu koordinieren.

Damit die Autonomie nicht im Chaos endet, bedarf es einer gemeinsamen Ausrichtung. Dazu gruppieren sich Squads mit ähnlichen Aufgaben zu sogenannten Tribes. Der „Häuptling“ eines solches Stammes schwört die Squads auf die prioritären Themen ein. Dazu werden auch Managementsysteme wie OKR (Objectives & Key Results) eingesetzt. In manchen Tribes finden sich ähnlich spezialisierte Fachkräfte, etwa Business-Analytiker, aus den Squads zu Ressorts (Chapter) zusammen. Der jeweilige Ressortleiter (Chapterlead) kümmert sich auch um die berufliche Entwicklung der Mitglieder. Für Initiativen oberhalb der Stammesebene können Mitarbeiter eine „Gilde“ gründen.

Wichtiger als die Projektmethoden sind hier die Firmenkultur und ihr technischer Unterbau. Das unterscheidet Spotify von den anderen Frameworks. Die allen zugängliche, einheitliche Technik minimiert den Koordinationsaufwand. Das setzt viel Vertrauen in die Mitarbeiter voraus. Darum stehen überdies kulturelle Faktoren im Vordergrund: Intrinsische Motivation und ein Gefühl der Sicherheit fördern die Experimentierfreude, die wiederum eine steile Lernkurve und rasche Anpassung ermöglicht.