Wann braucht es agile Skalierung?
Ein einzelnes Scrum Team umfasst laut Scrum Guide typischerweise zehn oder weniger Personen. Wird ein Produkt so gross, dass ein Team nicht ausreicht, arbeiten mehrere Teams daran. Der Scrum Guide empfiehlt in diesem Fall, dass diese Teams dasselbe Product Goal, denselben Product Backlog und denselben Product Owner teilen und gemeinsam dieselbe Definition of Done einhalten [1]. Was er nicht beschreibt, ist die Abstimmung zwischen den Teams: Wie werden Abhängigkeiten gesteuert, wie entsteht ein gemeinsames, integriertes Ergebnis, wie wird über mehrere Teams geplant?
Hier setzen Skalierungsframeworks an. Sie bieten zusätzliche Rollen, Events und Artefakte für die Abstimmung über Teamgrenzen. Wichtig ist dabei eine nüchterne Vorfrage: Muss wirklich skaliert werden? Mehr Teams bedeuten mehr Abstimmung, mehr Abhängigkeiten und mehr Overhead. Oft lässt sich durch einen klareren Produktschnitt, weniger parallele Vorhaben oder eine bessere Architektur mit weniger Teams mehr erreichen.
Welche Skalierungsframeworks gibt es?
| Merkmal | Nexus | LeSS | SAFe |
|---|---|---|---|
| Herkunft | Scrum.org, Ken Schwaber | Craig Larman und Bas Vodde | Scaled Agile, Inc., Dean Leffingwell |
| Grössenordnung | etwa 3 bis 9 Scrum Teams | 2 bis 8 Teams, darüber LeSS Huge | von einem Release Train bis zum Portfolio |
| Zusätzliche Rollen | Nexus Integration Team | wenige, ein Product Owner für alle Teams | zahlreiche, etwa Release Train Engineer, Product Management, Systemarchitektur |
| Backlog | ein Product Backlog | ein Product Backlog | Backlogs auf Team-, Train- und Portfolio-Ebene |
| Charakter | leichtgewichtige Erweiterung von Scrum | Scrum für viele Teams, Organisationsvereinfachung | umfassendes Rahmenwerk mit vielen Konfigurationen |
| Einführungsaufwand | gering bis mittel | mittel, verlangt Organisationsänderungen | hoch, mit Schulungen und Rollenaufbau |
Die Angaben zu LeSS und SAFe beruhen auf vergleichenden Darstellungen der Frameworks [4]. Nexus richtet sich laut Nexus Guide an etwa drei bis neun Scrum Teams, die gemeinsam an einem Product Backlog arbeiten, und führt als zusätzliche Verantwortlichkeit das Nexus Integration Team ein [2]. LeSS setzt stark auf Vereinfachung der Organisation: wenige zusätzliche Rollen, ein Product Owner, ein Backlog. SAFe ist das umfassendste Rahmenwerk und reicht mit Agile Release Trains, Lean Portfolio Management und WSJF als Priorisierungsmodell bis in die Unternehmenssteuerung [3].
Wie funktioniert Nexus?
Nexus versteht sich als Exoskelett von Scrum: Es baut auf den bestehenden Scrum-Elementen auf und ergänzt sie um das Nötigste für die Integration mehrerer Teams. Das Nexus Integration Team, bestehend aus dem Product Owner, einem Scrum Master und weiteren Mitgliedern, ist dafür verantwortlich, dass in jedem Sprint ein integriertes Increment entsteht [2]. Hinzu kommen teamübergreifende Events wie ein gemeinsames Sprint Planning, ein Nexus Daily Scrum für Vertreterinnen und Vertreter der Teams sowie ein gemeinsames Sprint Review und eine teamübergreifende Retrospektive.
Nexus eignet sich für Organisationen, die bereits erfolgreich mit Scrum arbeiten und mehrere Teams an einem Produkt koordinieren müssen, ohne eine umfangreiche neue Struktur einzuführen. Der Schwerpunkt liegt auf Integration und Abhängigkeiten. Wer weiter wachsen will, stösst bei etwa neun Teams an die Grenze des Frameworks.
Was zeichnet LeSS aus?
Large-Scale Scrum, kurz LeSS, verfolgt den Ansatz, Scrum für viele Teams möglichst unverändert anzuwenden und die Organisation drumherum zu vereinfachen. Ein Product Owner und ein Product Backlog gelten für alle Teams, die in einem gemeinsamen Sprint arbeiten. Für mehr als acht Teams sieht LeSS Huge Anforderungsbereiche mit eigenen Area Product Owners vor [4]. LeSS stellt hohe Anforderungen an die Organisation: Abteilungsgrenzen, Hierarchien und spezialisierte Rollen werden oft hinterfragt. Das macht LeSS wirksam, aber auch anspruchsvoll in der Einführung.
Wann passt SAFe?
Das Scaled Agile Framework ist das umfassendste und verbreitetste Skalierungsframework in grossen Organisationen. Es organisiert Teams in Agile Release Trains, die gemeinsam in festen Intervallen planen und liefern, und ergänzt Ebenen für grosse Lösungen und das Portfolio. Für die Priorisierung auf allen Ebenen nutzt SAFe WSJF [3]. SAFe bietet Organisationen mit vielen Teams, komplexen Abhängigkeiten und regulatorischen Anforderungen viel Struktur und Orientierung.
Die Kehrseite ist der Umfang: SAFe führt viele Rollen, Events und Artefakte ein und verlangt erhebliche Investitionen in Schulung und Aufbau. Kritiker sehen die Gefahr, dass klassische Steuerungsmuster unter neuen Namen weiterbestehen. Für kleine und mittlere Organisationen ist SAFe meist überdimensioniert.
Welches Framework passt zu welcher Organisation?
| Situation | Empfehlung |
|---|---|
| Zwei bis drei Teams an einem Produkt | zunächst ohne Framework: gemeinsames Planning und Review, abgestimmte Definition of Done |
| Drei bis neun Teams, Scrum etabliert, Integration ist das Hauptproblem | Nexus |
| Viele Teams an einem Produkt, Bereitschaft zur Organisationsvereinfachung | LeSS oder LeSS Huge |
| Viele Teams, mehrere Produkte, Portfolio-Steuerung und Regulierung | SAFe |
| Teams arbeiten an unabhängigen Produkten | keine Skalierung nötig, Portfolio-Abstimmung genügt |
Was muss vor dem Skalieren funktionieren?
- Einzelne Teams liefern regelmässig fertige Ergebnisse nach einer gemeinsamen Definition of Done.
- Es gibt einen klaren Produktschnitt und eine Person, die über die Prioritäten entscheidet.
- Technische Praktiken wie automatisierte Tests und kontinuierliche Integration ermöglichen häufige Integration.
- Führungskräfte unterstützen selbstmanagende Teams und geben Entscheidungsbefugnisse ab.
- Abhängigkeiten zwischen Teams sind bekannt und werden aktiv reduziert, nicht nur verwaltet.
Skalierung verstärkt, was bereits da ist. Funktioniert ein einzelnes Team nicht gut, werden zehn Teams die Probleme verzehnfachen. Deshalb lohnt es sich, zuerst ein oder zwei Teams zum Erfolg zu führen und erst dann zu skalieren. Wie die Einführung in kleineren Organisationen gelingt, beschreibt der Beitrag Agile Transformation in KMU; Grundlagen zu Scrum bietet der Beitrag Scrum Guide 2020 verständlich erklärt.
Skalierung im Werkzeug abbilden
Mehrere Teams an einem Produkt brauchen ein gemeinsames Bild: einen Backlog, sichtbare Abhängigkeiten, gemeinsame Termine und Auswertungen über alle Teams. In Flenio lassen sich Projekte mit mehreren Boards und gemeinsamen Meilensteinen führen und Auslastung über Teams hinweg verfolgen. Für SAFe-spezifische Strukturen wie Release Trains und Portfolio-Kanban sind spezialisierte Werkzeuge verbreitet. Einen kurzen Überblick bietet das Glossar unter SAFe. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.
Was ist ein Scrum of Scrums?
Ein Scrum of Scrums ist die einfachste Form der Abstimmung zwischen Teams. Vertreterinnen und Vertreter jedes Teams treffen sich regelmässig, oft mehrmals pro Woche, um Abhängigkeiten, Hindernisse und Integrationsfragen zu besprechen. Es ist kein vollständiges Framework, sondern eine Praxis, die sich für zwei bis vier Teams oft bewährt, bevor ein umfassenderes Framework nötig wird. Viele Organisationen beginnen damit und entscheiden erst später, ob sie Nexus, LeSS oder SAFe einführen.
Wie wird ein Skalierungsframework eingeführt?
Unabhängig vom Framework hat sich ein schrittweises Vorgehen bewährt. Zuerst wird der Produktschnitt geklärt: Welche Teams arbeiten an welchem Produkt, wer ist Product Owner, welche Abhängigkeiten bestehen? Danach werden gemeinsame Grundlagen geschaffen: ein gemeinsamer Backlog, eine gemeinsame Definition of Done, abgestimmte Sprintrhythmen. Erst dann folgen zusätzliche Rollen und Events des gewählten Frameworks. Nach einigen gemeinsamen Zyklen wird ausgewertet, ob die Abstimmung funktioniert und wo nachgeschärft werden muss.
Ein häufiger Fehler ist, ein Framework vollständig und auf einen Schlag einzuführen, inklusive aller Rollen und Events, ohne dass die Teams die Grundlagen beherrschen. Das erzeugt viel Aufwand und wenig Wirkung. Ein zweiter Fehler ist, Skalierung als Ersatz für Vereinfachung zu nutzen: Statt Abhängigkeiten zu reduzieren, werden sie mit zusätzlichen Meetings verwaltet. Langfristig wirksamer ist es, Teams so zu schneiden, dass sie möglichst unabhängig liefern können, etwa entlang von Kundenbedürfnissen statt technischer Komponenten.
Skalierung im DACH-Raum
Im DACH-Raum ist SAFe besonders in grossen Unternehmen, Banken, Versicherungen und der öffentlichen Verwaltung verbreitet, während LeSS und Nexus eher in produktorientierten Softwareunternehmen anzutreffen sind. In der Schweizer Bundesverwaltung wird agiles Arbeiten häufig mit HERMES agil kombiniert, das für mehrere Teams Programmstrukturen vorsieht. Für kleine und mittlere Unternehmen genügt meist eine schlanke Abstimmung ohne umfassendes Framework. Entscheidend ist nicht, welches Framework gewählt wird, sondern dass die Teams selbst gut funktionieren und die Organisation bereit ist, Entscheidungen näher an die Teams zu verlagern.
Ein guter erster Schritt für Organisationen mit mehreren Teams ist deshalb eine ehrliche Bestandsaufnahme: Wie viele Teams arbeiten tatsächlich am selben Produkt, welche Abhängigkeiten bestehen, und wo entstehen heute Wartezeiten? Die Antworten zeigen, ob ein Framework nötig ist oder ob eine bessere Aufteilung der Arbeit genügt. Oft ist die zweite Option günstiger und wirksamer. Weniger Abhängigkeiten schlagen fast immer mehr Koordination.