Wie in der Kritik zu Scrum erwähnt, sind solche agilen Vorgehensmodelle eher für kleine Teams oder Projekte konzipiert. Sobald mehrere Teams an einem Produkt bzw. Projekt arbeiten ist es sinnvoll ein Skalerungsframework zu nutzen, das versucht den Rahmen von Scrum auf größere Organisationen abzubilden.
1. Scaled Agile Framework (SAFe)
SAFe bettet die agile Entwicklung in ein Framework ein, dass die klassischen Unternehmensbereiche von großen Organisation mit einbezieht. Dabei bildet SAFe eine stabile Organisationsstruktur, die sich über mehrere Teams oder sogar Portfolios verteilt. Unter direkter Einbeziehung von Kanban werden verschiedene Backlogs mit Fokus auf Features und Architektur gepflegt und es gibt diverse Erweiterungen von Scrum durch zusätzliche Rollen, Aktivitäten und Artefakte, wie z. B. dem Product Management oder dem Release-Planning.
SAFe definiert drei Sichten auf den erweiterten Scrum-Prozess:
-
Portfolio: Entscheidungen über strategische Themen, die als Einträge in das Programm übernommen werden
-
Programm: Portfolio-Einträge werden in Feature-Einträge für die Backlogs umgewandelt
-
Team: Mehrere koordinierte Entwicklungsteams bearbeiten die Backlog-Einträge
2. Large-Scale Scrum (LeSS)
LeSS definiert vor allem Hierarchien von Product-Ownern, deren Verantwortungsbereich je Ebene immer kleiner wird. Außerdem erweitert LeSS den Scrum-Prozess dahingehend, dass über abgewandelte oder neue Aktivitäten die Arbeit der einzelnen Entwickler-Teams synchronisiert wird.
3. ScALeD Agile Lean Development
ScALeD liefert keine Vorgaben für Aufbau- und Ablauforganisation und ist auch kein Framework im eigentlichen Sinne. Stattdessen werden durch ScALeD Prinzipien formuliert, die das agile Gedankengut unter Gesichtspunkten der Skalierung formulieren.
Dadurch wird eher eine Meta-Sicht auf den Scrum-Prozess vorgegeben, deren Ziel es ist, selbstständig die optimale Aufbau- und Ablauforganisation für die eigene Organisation bzw. das eigene Projekt zu finden.
Die ScALeD-Prinzipien, die auf der Webseite[1] in ausführlicher Form nachzulesen sind, sind folgende:
- Begeisterte Kunden
-
-
Definiere, was Wert bedeutet und schafft
-
Produziere kleine, lieferbare Inkremente
-
- Zufriedene, produktive Mitarbeiter
-
-
Bilde eigenständige, funktionsübergreifende Teams
-
Bevollmächtige und befähige die Mitarbeiter
-
- Globale Optimierung
-
-
Schaffe Transparenz in alle Richtungen
-
Bevorzuge den persönlichen Kontakt
-
Schaffe Flow und Rhythmus
-
- Unterstützende Führung
-
-
Setze Ziele und Rahmenbedingungen
-
Dezentralisiere Kontrollstrukturen
-
Kultiviere den Wandel und wandle die Kultur
-
- Kontinuierliche Verbesserung
-
-
Überprüfe das Produkt und passe es an
-
Überprüfe den Entwicklungsprozess und passe ihn an
-
Überprüfe die Organisation und passe sie an
-
4. Agile Scaling Cycle
Weil die ScALeD-Prinzipien in der Praxis nicht ausreichend sind, um in Organisationen oder Projekten gewinnbringend eingeetzt werden, gibt es den Agile Scaling Cycle. Was Scrum für das Agile Manifest ist, ist der Agilge Scaling Cycle für die ScALeD-Prinzipien, der agilen Skalierung.
Der Agile Scaling Cycle besteht aus drei einfachen Schritten, in deren Zentrum die agilen Werte und Prinzipien stehen. Für die einzelnen Schritte gibt es eine Reihe von möglichen Best-Practices, für die ich ebenfalls einige Beispiele zeige.
- Schritt 1: Abhängigkeiten reduzieren
-
Begonnen wird mit der Reduktion von Abhängigkeiten zwischen den Teams. Es wird geprüft, wie die Kommunikation zwischen den Teams aber auch den anderen Beteiligten, wie dem Product-Owner, reduziert werden kann, ohne dass Informationen verloren gehen oder die Kommunikation unnötig fomalisiert wird.
- Schritt 2: Teams koordinieren
-
Dann wird geprüft, welche Methoden geeignet sind, um die Teams an den entscheidenden Punkten zu koordinieren oder zu synchronisieren. Generell gilt als Maß: je weniger Maßnahmen zur Koordination, desto besser! Schließlich sollen die Abhängkeiten reduziert und nicht verkompliziert werden.
- Schritt 3: Unternehmen entwickeln
-
Im Scrum-Prozess, aber auch entlang des Agile Scaling Cycle werden Hindernisse auftreten, die weder die Teams noch der Scrum-Master beseitigen können. Hierfür wird ein Transitionsteam eingeführt, das selbst nach Scrum arbeitet und entsprechend hochrangig besetzt sein muss, damit es weitreichende organisatorische Änderungen veranlassen kann. Die großen, organisatorischen Hindernisse wandern ins Transitions-Backlog und werden vom Transitionsteam bearbeitet, dass diese umsetzen und den organisatorischen Nutzen dieser Änderungen rechtfertigen kann.