Digitalisierung ist ein Megatrend über alle Industrien hinweg. Nahezu alle Unternehmen müssen ihr Geschäftsmodell digitalisieren und dazu neue digitale Produkte und Services erschaffen. Deshalb haben sich in den letzten Jahren viele Unternehmen neu strukturiert. Denn durch die jahrzehntelange Arbeit in Silos, sowohl funktional als auch divisional, sind organisationale Hürden entstanden.

Diese Art der Organisation hat die Mitarbeiter nachhaltig geprägt. Folglich wird nicht nur in Silos gearbeitet, sondern vor allem auch in ihnen gedacht. Damit eng verbunden ist der Wunsch und gleichzeitig die Herausforderung nach Agilisierung der Arbeit. In der Vergangenheit wurde für die agile Zusammenarbeit Scrum als klassisches agiles Projektmanagement-Framework eingesetzt. Dieses Framework setzt seine Grundlage auf die Selbstorganisation der Teammitglieder und stellt den Kunden in den Mittelpunkt des Handelns.

Heutzutage stehen vor allem größere Organisationen vor der Herausforderung, dass sich agile Frameworks wie Scrum auf einzelne Projekte und Teams mit bis zu neun Mitgliedern beziehen. In der Praxis bietet das für Unternehmen mit großen Projektvorhaben und vielen Teammitgliedern keine Lösung. Durch die gesteigerte Anzahl an Mitgliedern in größeren Projekten steigt auch die Anzahl der Abhängigkeiten untereinander und folglich die Komplexität.

Genau für diese Problemstellung bieten skalierte Frameworks einen Lösungsansatz, um Scrum als Methode auch im großen Rahmen und für eine große Anzahl von Produktteams zu nutzen. Dabei können Unternehmen auf verschiedene Skalierungsframeworks zurückgreifen. Diese Frameworks sind in der Regel auf Basis von Scrum oder weiteren agilen Methoden entwickelt worden. Die wichtigsten und in der Praxis geläufigsten Frameworks sind Scaled agile Framework (Safe), Large Scale Scrum (Less) und Nexus. Welches Framework ist also für welches Unternehmen am besten geeignet und warum?

Lerne jetzt in unserem Videokurs die Grundlagen der Agilität kennen!

Safe dient als Framework, um eine agile Entwicklung in eine Organisation einzubetten und zu fördern. Gleichzeitig bindet es klassischen Unternehmensbereiche ein. Das Framework setzt sich in seiner Basisvariante Portfolio Safe aus der Team,- Programm,- und Portfolioebene zusammen. Auf Portfolioebene werden strategische Themen mithilfe eines Portfolio-Canvas bewertet und anschließend in die zu leistende Arbeit aufgeteilt. In der nachfolgenden Programmebene werden in sogenannten Agile-Release-Trains Mitglieder agiler Scrum-Teams mit weiteren Interessensgruppen gebündelt. Sie bilden zusammen eine dauerhafte Gruppe, die digitale Lösungen sukzessive entwickelt und kontinuierlich in Releases ausliefert.

Das Bindeglied zwischen Programm- und Teamebene bildet das Program-Increment-Planning. Hier legen die Teams an bis zu zwei Tagen gemeinsam die Planung fest, welche Inkremente innerhalb der nächsten acht bis zwölf Wochen Iteration umgesetzt werden sollen. Safe setzt sich auf jeder Ebene aus der Interaktion unterschiedlicher Rollen, Artefakte und Methoden zusammen. Ein großer Vorteil von Safe besteht darin, komplexe Systeme mit einer hohen Anzahl von Teams und vielen Abhängigkeiten zu unterstützen. Das Framework bietet großen Organisationen, die noch nicht agil sind, die Chance, dauerhaft agil zu arbeiten. In der Praxis gelingt das durch die strukturierte Vorgehensweise über mehrere Ebenen hinweg. Zudem ermöglichen die Konfigurationsmöglichkeiten individuelle Anpassungen an eigene Bedürfnisse.

Ein Nachteil von Safe ist eine Tendenz zur Inflexibilität. Die entsteht durch die vielen Ebenen mit zusätzlichen Rollen und Abhängigkeiten sowie der damit verbundenen Top-down-Orientierung. Die hierarchische Struktur frisst Agilität. Es besteht die Gefahr, dass bei der Implementierung von Safe agil zu mechanistisch gelebt wird und wenig menschlich. Zudem mangelt es bei Safe häufig an einer End-to-End-Verantwortung, was eine schnelle und kundenzentrierte Umsetzung erschwert. Die Probleme entstehen dadurch, dass die Produkte der einzelnen agilen Teams nicht aufeinander abgestimmt sind und somit nicht auf das strategische Gesamtziel einzahlen.

Less als weiteres Skalierungsframework ist in seiner Basisvariante für acht Teams konzipiert worden. Die Erweiterung Hugh Less ermöglicht die Steuerung über acht Teams bis hin zu mehreren Tausend Personen und den Einsatz in mittelgroßen Organisationen. Getreu dem Motto „Less is more“ sticht das Framework vor allem durch seine einfache Struktur heraus, da es bereits auf funktionierende Scrum-Teams aufbaut. Diese Teams sind unter der Steuerung von einem einzigen Product-Owner für die agile Produktentwicklung zuständig. Bei der Erweiterung auf Hugh Less arbeiten jeweils vier bis acht Teams unter einem Area-Product-Owner. Das Less-Framework zeichnet sich durch drei wesentliche Grundelemente aus: Prinzipien, Regeln und Experimente. Sie ermöglichen als organisatorischer Rahmen den verschiedenen Scrum-Teams, so effektiv wie möglich agil zusammenzuarbeiten. In Summe besticht Less somit durch seine geringe Komplexität sowie einer starken Ausrichtung an agilen Grundprinzipien. Zusätzlich sind die vergleichsweise geringen Einführungskosten und guten Skalierungsmöglichkeiten von Product-Ownern von Vorteil.

Dem gegenüber stehen aber auch Nachteile. Als radikaler Ansatz ist die Integration in größeren Organisationen schwierig. Zudem ist die Skalierung mit Scrum-Teams bis zu einer gewissen Größe limitiert und eignet sich primär für mittelgroße Unternehmen. Im Vergleich zu Safe gibt es außerdem keinerlei Auskunft und Regelung hinsichtlich Strategie, Architektur und Portfolio.

Nexus als drittes Framework ist eine schlanke Erweiterung von Scrum. Neben den maximal neun parallel arbeitenden Scrum-Teams wird lediglich das Nexus-Integration-Team als zusätzliches Team integriert. Die Hauptaufgabe dieses Teams besteht darin, für ein einheitliches Verständnis und Einsatz der notwendigen Praktiken sowie Werkzeugen in den Scrum-Teams zu sorgen. Ein klarer Vorteil von Nexus gegenüber Safe und Less liegt in dem minimalistischen Aufbau und einhergehenden geringen Formalisierungsgrad. Im Umkehrschluss bedeutet das, dass für die konkrete Ausgestaltung und Überführung in die Geschäftspraxis ein hoher Anteil an Eigenleistung notwendig ist. Gegenüber den beiden anderen Branchenführern hat Nexus in der Praxis einen weitaus geringeren Verbreitungsgrad. Analog zu Less gibt Nexus dem Anwender keine Auskunft darüber, wie die agilen Prozesse mit Strategieprozessen, Portfoliomanagement oder Betrieb zusammenhängen.

Kommen wir nach der Erläuterung der Skalierungsframeworks zur Frage nach dem präferierten Framework zurück. Die Antwort ist schnell gegeben. Es gibt nicht das optimale Framework, das auf jedes Unternehmen passt. Jedes Unternehmen muss hier einen eigenen Weg finden und das Framework auswählen, das am besten zur eigenen Situation und den individuellen Umständen passt. Dabei gilt es, das Framework nicht 1:1 zu kopieren und zu versuchen, jedes Detail krampfhaft zu implementieren. Stattdessen muss das Framework so angepasst und entwickelt werden, dass die Organisation und Mitarbeiter befähigt werden, agil zu arbeiten.

Letztlich bleiben Skalierungsframeworks nur eine Methode, die zwar direkt sichtbar ist, dafür aber langfristig wirkungslos bleibt. Das resultiert häufig aus einem Leadership-Problem: Frameworks werden ad hoc für die agile Zusammenarbeit eingeführt, aber das Mindset ist nicht agil. Frameworks zur Skalierung können nur funktionieren, wenn sich die Organisationsstrukturen und das Mindset der Mitarbeiter ändern. Das heißt konkret: Bestehende hierarchische und politische Strukturen müssen aufgelöst werden. Wirkungsvoller ist die Entwicklung hin zu einer lernenden Organisation, die sich mit den Mitarbeitern an veränderte Umweltbedingungen permanent anpassen kann. Ohne diese Voraussetzung ist die Implementierung von agilen Skalierungsframeworks oder anderen agilen Methoden nicht effektiv.