01. August 2019

Agile Skalierung: Welche Frameworks eignen sich für die klassischen Industrien?

SMART DEVELOPMENT NEWS 09/2017

Das Ziel agiler Arbeitsweisen ist die wertorientierte, regelmäßige, zuverlässige und fehlerfreie Lieferung von Produktinkrementen. Zwei Erfolgsfaktoren sind kleine, eigenverantwortliche, sich selbst steuernde, cross-funktionale Teams sowie empirische Prozesskontrolle. Aber: Mit einem kleinen Team können wir keine umfangreicheren, komplexen Entwicklungsvorhaben realisieren. Die zentrale Frage ist also: Wie können wir die Vorteile der Agilität auch im Großen beibehalten? Hier kommen die verschiedenen agilen Skalierungs-Frameworks ins Spiel.

Gründe für die Skalierung

Die meisten Unternehmen sammeln zunächst Erfahrungen im Umgang mit agilen Prinzipien. Das tun sie, indem sie Scrum oder Kanban in überschaubaren Pilotprojekten oder ausgewählten Entwicklungsbereichen einsetzen. Das ist auch richtig so.

• Sie können so überprüfen, ob sich der erwartete Nutzen in Form einer höheren Geschwindigkeit, einem effektiveren Umgang mit sich ändernden Produktanforderungen und Prioritäten, einer gesteigerten Produktivität und einer höheren Produktqualität auch wirklich einstellt.
• Sie sammeln erste Erfahrungen hinsichtlich des veränderten Führungs- und Arbeitsverhaltens, was letztlich zu einer veränderten Unternehmenskultur führt.

Unternehmen finden also heraus, ob sie bereit sind für eine agile Transformation – und ob diese Ihnen eindeutige Vorteile bringt. Werden beide Fragen positiv beantwortet, befördern Unternehmen das agile Mindset. Agile Führung und Arbeitsweisen werden dann weiter ausgerollt:

• Weitere Projekte oder Entwicklungsgruppen werden Scrum oder Kanban anwenden.
• Umfangreiche und komplexe Projekte werden agil durchgeführt.
• Ganze Wertströme werden agil.
• Die gesamte Organisation wird agil.

Für den Einsatz in größeren Organisationen ist die agile Methode Scrum allerdings nicht entwickelt worden. Sie entfaltet ihre volle Wirkung in einem oder mehreren kleinen Teams mit einer überschaubaren Zahl an Mitarbeitern. In größeren Gruppen leidet die direkte Kommunikation und es droht ein Transparenzverlust. Damit die Vorteile agiler Methoden auch im Großen zum Tragen kommen, entstanden in den vergangenen Jahren verschiedene Skalierungs-Frameworks, innerhalb derer auch eine größere Zahl an Teams gemeinsam „agil“ an einem Produkt oder Wertstrom arbeiten kann.

Wenn möglich Skalierung vermeiden

Komplexität ist also der Treiber der Skalierung und kleine Teams funktionieren besser als große Teams. Prüfen Sie daher vor jeder Skalierung, ob die Komplexität nicht aus einer suboptimalen Herangehensweise resultiert. Wenn Sie Aufgabenstellung, Teamschnitte und Teamzusammensetzung so optimieren können, dass sich die Komplexität reduziert, ist eine Skalierung vielleicht vermeidbar.

Skalierungs-Frameworks im Überblick

Die agilen Skalierungs-Frameworks unterscheiden sich zum Teil erheblich in ihrer Grundidee und Komplexität. Sich für das richtige Framework zu entscheiden, ist also einerseits gar nicht so einfach. Andererseits gilt auch für die agile Skalierung das Prinzip der empirischen Prozesskontrolle. Es hilft also nicht, ein agiles Framework dogmatisch einzuführen. Wichtiger ist es, die agilen Prinzipien konsequent anzuwenden, Erfahrungen zu sammeln und zu adaptieren. Dadurch entsteht aus lernenden Teams eine lernende Organisation. Einige Frameworks stellen dieses Selbstverständnis stärker heraus als andere.

Trotzdem schaffen die eher präskriptiven agilen Skalierungs-Frameworks aufgrund ihrer Struktur und Systematik Vertrauen und bieten ein höheres Sicherheitsgefühl beim Finden einer guten Ausgangskonfiguration. Dies gilt gerade bei Führungskräften, die noch keine große Erfahrung mit agilen-Methoden haben. Wir wollen uns in diesem Beitrag auf vier Frameworks beschränken: SAFe®, LeSS®, Scrum@Scale® und Nexus®.

Alle agilen Frameworks lassen sich übrigens genauso für die Entwicklung physischer Produkte nutzen wie auch Scrum selbst. Die wesentliche Adaption besteht darin, nicht jedes potentially shippable increment wie in der Software-Entwicklung als vollständig integriertes und getestetes System aufzufassen. Vielmehr verwenden wir eine abstraktere Definition, die die Möglichkeit eines validen Feedbacks der Kunden und Stakeholder im Review fokussiert.

Gemeinsamkeiten der Frameworks

Alle agilen Skalierungs-Frameworks haben sich aus der praktischen Erfahrung mit Scrum entwickelt. Daher haben sie viele Gemeinsamkeiten:

• Alle besitzen den Anspruch, modular aufgebaut und kontextbezogen adaptierbar zu sein.
• Die Skalierung erfolgt über zusätzliche vertikale Ebenen und eine horizontale Verbreiterung.
• Die agilen Prinzipien gelten weiter.
• Scrum ist die Grundlage der Zusammenarbeit auf Teamebene.
• Die Scrum-Rollen (Product Owner, Scrum Master, Development Team) bleiben grundsätzlich erhalten.
• Neue Strukturelemente werden hinzugefügt.
• Teams arbeiten produktbezogen an einem Backlog und einem integrierten Product Increment.
• Backlogs sind vertikal miteinander verbunden; ihr Detaillierungsgrad steigt von Ebene zu Ebene.
• Teams arbeiten in einem synchronisierten Takt.
• Teams verlieren einen Teil ihrer Autonomie.

Scaled Agile Framework SAFe®

Das Scaled Agile Framework (SAFe®) bietet traditionellen Unternehmen eine klare Orientierung für den Start, umfasst konkrete Praktiken für eine tiefgreifende Umgestaltung des Gesamtunternehmens, akzeptiert aber klassische Organisationsstrukturen. Im Vergleich zu den anderen Frameworks, um die es in diesem Beitrag geht, umfasst dieser Strukturrahmen auch eine agiles strategisches Portfolio- und Budgetmanagement. Als zweites Unterscheidungsmerkmal bietet SAFe® eine Implementation Roadmap mit sehr konkreten Empfehlungen für die Einführung. Der präskriptive Charakter des Frameworks unterstützt deutlich weniger, als die anderen hier dargestellten Frameworks, die Idee einer spezifischen Anpassung an die jeweilige Unternehmensorganisation.

Zentrales Element von SAFe® ist das Denken in Wertströmen und Systemen. Unternehmen, die physische Produkte entwickeln, ist dieses Denken bereits sehr vertraut. Wertströme reichen von einem Auslöser wie einer Innovationsidee oder einem Kundenauftrag bis hin zur Auslieferung. Der darin enthaltene Entwicklungswertstrom ist also eine Kombination aus Prozessen, zum Beispiel dem interdisziplinären Produktentstehungsprozess, und einer Produktgruppe, zum Beispiel Mähdrescher, Traktoren oder Futtererntemaschinen. SAFe® löst sich vollständig vom Projektgedanken und organisiert Menschen und Budgets um kontinuierliche Wertströme.

SAFe® wurde erstmals 2011 in der Version 1.0 veröffentlicht und wird heute in der Version 4.5 angewendet. In dieser Version stehen vier Grundkonfigurationen zur Verfügung:

• Essential SAFe® als Einstiegskonfiguration (2 Ebenen)
• Portfolio SAFe® erweitert Essential SAFe® um ein agiles Portfolio-Management (3 Ebenen)
• Large Solution SAFe® für Organisationen, die keinen Einfluss auf das Portfolio-Management haben, aber mit mehr als 125 Personen an einem Produkt arbeiten wollen (3 Ebenen)
• Full SAFe® als vollständiges Framework (4 Ebenen)

SAFe® arbeitet also mit bis zu vier Ebenen, um eine durchgängige Verbindung von der Unternehmensstrategie bis hin zum agilen Team zu erreichen:

• Portfolio
• Large Solution
• Program
• Team

Das kleinste Team of Teams ist ein Agile Release Train. Er umfasst mehrere Scrum- oder Kanban-Teams und hat angelehnt an die Dunbar-Zahl typischerweise 50 bis 125 Teammitglieder. Mehrere Agile Release Trains bilden einen sogenannten Solution Train, der einem Wertstrom zugeordnet wird. Entwicklungslieferanten gelten wiederum als eigener Agile Release Train. Die Portfolio-Ebene steuert mehrere Wertströme.

Backlogs sind über alle vier Ebenen miteinander verknüpft und werden von „oben“ nach „unten“ detaillierter. Aus strategischen Themen werden EPICs, Capabilities, Features und Stories. Der Fluss dieser Backlog Items wird auf allen Ebenen über Kanban Boards visualisiert.

Teams innerhalb eines Agile Release Trains und Agile Release Trains innerhalb eines Solution Trains arbeiten synchronisiert und nach dem gleichen Takt. Team-Sprints werden wie bei Scrum durchgeführt. Für den Agile Release Train gibt es eine übergeordnete Synchronisation, typischerweise im 10-Wochen-Takt: das Program Increment. Die Abstimmung in den agile Release Trains erfolgt über Scrum of Scrums, Product Owner Sync und ART Sync Meetings.

Auch für die Implementierung existiert eine definierte Roadmap. Die Skalierung beginnt mit der Auswahl eines Wertstroms und mindestens eines dazugehörigen Agile Release Trains.

SAFe® kann als das komplexeste Framework angesehen werden. Im Vergleich zu anderen Frameworks führt es mehr neue Rollen, Events und Artefakte ein. Aber es liefert auch eine Lösung für die agile Kombination aus strategischem Portfolio-Management und Produktentstehung. Die durchdachte Struktur und konkrete Praktiken scheinen einerseits dem Prinzip der empirischen Prozesskontrolle zu widersprechen. Andererseits erzeugt genau diese Struktur und Systematik Vertrauen und Sicherheit. Zudem dürfte der präskriptive Charakter das Mindset vieler Führungskräfte aus dem Bereich der klassischen Fertigungsindustrie ansprechen.

Large Scale Scrum LeSS®

Im Vergleich zu SAFe® hat das 2008 publizierte LeSS®-Framework den Anspruch, wesentlich näher am Standard-Scrum zu bleiben. Ein zentrales Prinzip lautet: „Large Scale Scrum ist Scrum“. Daher beinhaltet es weniger feste Strukturvorgaben als SAFe® und lässt Unternehmen bei der Implementierung vergleichsweise mehr Flexibilität. Bei LeSS® geht also weniger darum, vorgegebene Prozesse in einem Unternehmen zu etablieren, sondern eher darum, Dysfunktionen durch kontinuierliches Lernen selbstständig zu erkennen und möglichst einfach zu beseitigen. LeSS® richtet sich also eher an Unternehmen, die bereit sind, traditionelle Organisationsformen radikal zu verändern. Dennoch gibt es auch hier Prinzipien und Regeln, ohne die LeSS® nicht seine volle Wirksamkeit entfaltet.

Es stehen zwei Grundkonfigurationen zur Verfügung:

• LeSS® mit einem Product Owner für zwei bis acht Teams
• LeSS Huge® mit einem Product Owner und mehreren Area Product Ownern mit jeweils vier bis acht Teams.

Für beide Grundkonfigurationen gilt:

• Es gibt einen Product Owner, der ein Product Backlog verantwortet.
• Es gibt eine Definition of Done.
• Alle Teams arbeiten getaktet und synchronisiert in einem Sprint.
• Alle Teams arbeiten gemeinsam an einem Produktinkrement.

LeSS® beinhaltet vier sehr gut dokumentierte Strukturelemente:

• Prinzipien - Zehn Prinzipien unterstützen Entscheidungen zur kontextspezifischen Anwendung der allgemeinen Regeln
• Regeln - 28 Regeln zu LeSS® und 13 Regeln zu LeSS Huge® unterstützen die Umsetzung der Prinzipien
• Wegweiser - Tipps zur effektiven Umsetzung der Regeln
• Experimente - Zum situativen Ausprobieren

Die Sprint-Planung wird zweigeteilt: Die Sprint-Planung 1 führen bei LeSS® alle Teams und bei LeSS Huge® die Teams einer Area über Stellvertreter der Teams gemeinsam durch. Die Sprint-Planung 2 gestaltet jedes Team einzeln. Die Teams führen ihre Daily Scrums unabhängig voneinander durch. Einzelne Teammitglieder nehmen aber für den Informationsaustausch auch an Daily Scrums anderer Teams teil. Am Ende des Sprints finden für alle Teams bei LeSS® (oder für die Teams einer Area bei LeSS Huge®) ein gemeinsames Sprint Review und eine gemeinsame Retrospektive statt. Zusätzlich macht jedes Team seine eigene Retrospektive.

Bei jeder Skalierung besteht die Gefahr, Aufwand und Kosten unnötig zu erhöhen. LeSS® plädiert deshalb dafür, die Dinge so einfach wie möglich zu tun. LeSS® steht eben nicht nur für Large Scale Scrum sondern auch für „less“. Best Practices sind ein Hindernis für kontinuierliches Lernen. Daher möchte LeSS® als deskriptiver Ansatz möglichst keine konkreten Vorgaben machen, wie Prinzipien und Regeln umzusetzen sind.

Scrum@Scale®

Ähnlich wie LeSS® ist auch das Scrum@Scale®-Framework dem klassischen Scrum-Ansatz wesentlich ähnlicher, als dies bei SAFe® der Fall ist. Im Gegensatz zu LeSS® ist es allerdings noch weniger ausführlich ausdefiniert und dokumentiert. So beinhaltet es unter anderem eine Reihe von Modulen (siehe unten), die allerdings nicht alle sofort implementiert werden müssen, damit sich der Erfolg der Methode einstellt. Dadurch ermöglicht Scrum@Scale® letztlich spezifischere, flexiblere Lösungen für die agile Transformation einer Unternehmensorganisation.

Scrum@Scale® wurde 2014 von Jeff Sutherland, einem der Erfinder des klassischen Scrum, vorgestellt. Wie LeSS® tritt es besonders stark für die Grundgedanken von Scrum ein. Das Framework betont kontextbezogene Adaptionen sowie die dafür notwendigen Freiheitsgrade für die konkrete Ausgestaltung einzelner Elemente. Das organisationale Lernen sollten Sie aber über eine Bibliothek bewährter, kontextbezogener Praktiken beschleunigen, die unternehmensübergreifend in einer Community aufgebaut werden.

Scrum@Scale® unterscheidet drei Ebenen:

• Unternehmen
• Geschäftseinheit
• Team

sowie zehn Module:

• Strategische Vision
• Backlog-Priorisierung
• Backlog-Zerlegung und Refinement
• Release-Planung
• Scrum auf Teamebene
• Release-Management
• Produkt- und Release-Feedback
• Kontinuierliche Verbesserung und Beseitigung von Hindernissen
• Teamübergreifende Koordination
• Metriken und Transparenz

Module werden über Ziele, Input und Output beschrieben. Solange diese unverändert bleiben, spielt es keine Rolle, wie das Modul ausgeführt wird.

Diese zehn Module werden über zwei große Feedback-Zyklen ausgeführt:

• Product Ownership Cycle (äußerer Kreis)
• Scrum Master Cycle (innerer Kreis)

Scrum@Scale® befürwortet ein iteratives und inkrementelle Vorgehen ganz im Sinne der empirischen Prozesskontrolle – anders als zum Beispiel SAFe® mit seiner klaren Implementierungs-Roadmap. Wichtig ist, sich zuerst über die Ziele der Unternehmensentwicklung klar zu werden und dann vorrangig die Module einzuführen, die zur Zielerreichung am meisten beitragen.  

Nexus®

Auch Ken Schwaber, der mit Sutherland an der Entwicklung von Scrum beteiligt war, bietet mit NEXUS® ein relativ neues Framework an. Es hat viele Ähnlichkeiten mit LeSS®, ist ebenfalls sehr stark am originären Scrum orientiert und verfolgt einen ähnlich minimalistischen Weg. Im Vergleich zu den anderen Frameworks, die wir in diesem Beitrag betrachtet haben, ist es deutlich weniger klar strukturiert.

Wie bei LeSS® stehen zwei Grundkonfigurationen zur Verfügung:

• Nexus für drei bis neun Teams
• Nexus plus® mit drei bis neun Nexus-Teams.

Die Teams werden so zugeschnitten, dass ihre Abhängigkeiten minimiert und so die Produktivität maximiert werden. Sie arbeiten an einem gemeinsamen Product Backlog Zusätzlich zu den Rollen von Scrum wird ein Nexus-Integrationsteam eingeführt. Zu diesem Team gehören der Product Owner, der Scrum Master sowie ein oder mehrere Teammitglieder. Das Integrationsteam sorgt für eine gut verzahnte und harmonische Zusammenarbeit der einzelnen Teams.

Als zusätzliches Artefakt wird ein integrierter NEXUS® Sprint Backlog aufgebaut. Die Scrum-Rituale Sprintplanung, Daily Scrum, Sprint Review und Retrospektive erfolgen übergeordnet und zusätzlich zu denen der einzelnen Teams. Das Sprint Review gibt es dann wie bei LeSS® nur einmal für das gemeinsame Produktinkrement. 15 technische Praktiken unterstützen die Zusammenarbeit.

Nexus® verfolgt ähnlich wie LeSS® einen stark am originären Scrum orientierten minimalistischen Weg.

Verbreitung

Prof. Dr. Ayelt Komus von der Hochschule Koblenz veröffentlicht regelmäßig eine Studie über Erfolg und Anwendungsformen agiler Methoden www.status-quo-agile.de. Diese Studie ist für Unternehmen im deutschsprachigen Raum, die physische Produkte entwickeln, deshalb interessant, weil 82% der 895 teilnehmenden Unternehmen aus der DACH-Region kommen. Davon geben immerhin schon 8% an, in der Produktentwicklung und nicht in der reinen Software-/IT-Entwicklung, der Beratung oder ähnlichen Bereichen tätig zu sein. Im Abschlussbericht: Status Quo Agile 2016/2017 gaben 139 Unternehmen an, agile Skalierungs-Frameworks zu nutzen.

Das Dilemma

Wie Sie gesehen haben, stehen Unternehmen aktuell eine ganze Reihe an Frameworks zur Verfügung, deren Grundideen und Strukturen sich zum Teil erheblich unterscheiden. Einerseits macht das den Auswahlprozess sehr aufwändig. Andererseits ermöglicht diese Diversität die Auswahl eines Frameworks, das sowohl zur Ausgangssituation als auch zur Zielsetzung des Unternehmens gut passt. Dabei spielen besonders die Unterschiede in der Flexibilität und Modularität eine große Rolle. Dennoch drohen hier Unsicherheiten.

Deskriptive Frameworks wie Scrum@Scale ermöglichen auf der einen Seite eine stufenweise und behutsame Einführung. Sie dürften daher auf den ersten Blick besonders gut zu Unternehmen mit traditionellen Strukturen und eingeschränkter Veränderungsbereitschaft passen. Wir erleben dies derzeit in einem unserer Beratungsprojekte, in dem wir einen skalierten Ansatz bei einem Automobilhersteller implementieren. Das Framework wird abhängig vom konkreten Handlungsbedarf des Unternehmens schrittweise eingeführt und so praktisch erfahrbar.

Auf der anderen Seite bedürfen diese flexiblen Frameworks wegen ihres deskriptiven Charakters besonders viel agiler Erfahrung hinsichtlich der Ausgestaltung einzelner Elemente. Dies kann den Lernprozess und die Implementierung verlangsamen und gefährden, wenn die internen oder externen Agile-Coaches keine konkreten kontextbezogenen Praktiken einbringen.

Präskriptive Ansätze wie SAFe® vermitteln traditionellen Unternehmen mehr Sicherheit, weil sie konkrete Praktiken und eine vorbereitete Implementierungs-Roadmap anbieten. Ihre Systematik und Strukturiertheit dürfte Führungskräfte, die komplexe klassische Projektmanagementsysteme und detaillierte Produktentstehungsprozesse gewohnt sind, eher ansprechen. Auch wird die klassische Aufbauorganisation nicht in Frage gestellt. Insofern könnte es leichter gelingen, Entscheider für eine agile Skalierung zu gewinnen.

Andererseits werden wegen der Komplexität des Frameworks besonders erfahrene interne oder externe Agile-Coaches gebraucht, um komplexe Events wie ein zweitägiges PI-Planning für einen Agile Release Train mit bis zu 125 Personen in einem Raum erfolgreich durchzuführen.

Ohne Veränderungsmanagement geht es nicht.

Für welches agile Skalierungs-Framework Sie sich auch entscheiden. Noch vielmehr als bei der Pilotierung von Scrum oder Kanban in kleinen Projekten gilt für die Skalierung:

• Setzen Sie ein begleitendes Veränderungsmanagement auf.
• Zeigen Sie die Notwendigkeit der Veränderung auf. Überzeugen Sie Ihre Mitarbeiter.
• Schulen Sie Ihre Führungskräfte. Nur so können sie ihre Teams als Servant Leader unterstützen.
• Sorgen Sie für pro-aktive Führung. Das Management muss agile Prinzipien verinnerlichen und vorleben.
• Schulen Sie Ihre Teammitglieder. Sorgen Sie für eine ausreichende Anzahl agiler Coaches.
• Generieren und kommunizieren Sie Quick-Wins.

Fazit

Agile Skalierungs-Frameworks stehen nicht im Widerspruch zu den Erfolgsfaktoren von Scrum und können auch in der Entwicklung physischer Produkte erfolgreich eingesetzt werden. Das agile Manifest und die agilen Prinzipien bilden bei allen Frameworks weiterhin das Fundament. Die höhere Komplexität stellt jedoch deutlich höhere Anforderungen an das Führungsverhalten, das Systemdenken auf Organisations- und Produktebene, die kontinuierliche Integrationsfähigkeit und die Zusammenarbeit verteilter Teams.