Agile Methoden wie Scrum sind meist auf den auf den Einsatz in einzelnen kleinen Teams hin konzipiert. Gibt es aber regelmäßig Vorhaben, die auch mit 2-3 solcher Teams nicht abzudecken sind, und womöglich mehrere dieser Vorhaben, die zentral gesteuert werden müssen, so kommt nicht selten das traditionelle Projektmanagement aus der Zeit der Erfindung der Atombombe und der ersten Mondlandung zum Einsatz, sprich: Ansätze, die man vor über fünfzig Jahren für einen völlig anderen Zweck erfunden hat. Viele der agilen Vorteile wie die Orientierung an Werten, häufiges Kundenfeedback, minimale Time-to-Market, schnelle Reaktion auf Änderungen bleiben dabei auf der Strecke. Die Zeit „from concept to cash“ wird wieder auf die Dauer des Apollo oder des Manhattan-Projekts verlängert.
Das Scaled Agile Framework® kombiniert Ansätze aus den agilen Methoden Scrum, Kanban und Extreme Programming mit Lean Thinking sowie den von Donald G. Reinertsen formulierten Prinzipien zum Lean Product Development und ermöglichst es so, Agilität im Enterprise Umfeld und großen Maßstab anzuwenden.
“As Scrum is to the Agile team, SAFe is to the Agile enterprise.”
– Dean Leffingwell
SAFe Big Picture: Die Konfigurationen von SAFe
SAFe wurde für den Einsatz unter ganz unterschiedlich komplexe Bedingungen konzipiert. „Out of the Box“ gibt es 4 verschiedene, einfach auswählbare Konfigurationen mit jeweils dazu sinnvollen Rollen, Artefakten und Aktivitäten:
- Essential SAFe
- Portfolio SAFe
- Large Solution SAFe
- Full SAFe
Essential SAFe: Der Einstiegspunkt für Organisationen, die die Vorteile von SAFe so schnell wie möglich umsetzen möchten
Team-Ebene
Die Teams organisieren sich „fast wie gewohnt“ nach einem leicht abgewandelten Scrum auf der Basis von XP-Praktiken in der der Größe von fünf bis neun Mitgliedern, einem Product Owner sowie einem Scrum Master.
Der Product-Owner arbeitet stark team-fokussiert, hat die Verantwortung für die Teilprodukte von 1-2 Teams und unterstützt auf Programm-Ebene das Product Management. Teams planen auf der Basis von Stories, die in einen Sprint / eine Iteration passen müssen.
Programm-Ebene
SAFe fasst Teams in den sogenannten Agile Release Trains (ART) zusammen. Fünf bis zehn Teams (ca. 50-125 Mitglieder) arbeiten in einem Train zusammen und bearbeiten die Herausforderungen eines sogenannten Programms (nicht eines „Projekts“ wohlgemerkt, das wäre ja etwas einmaliges, hier geht es um Flow). Ein großes Unternehmen hat typischerweise mehrere solcher Programme und zugehöriger Trains. Anforderungen werden vom Produkt-Manager als Features auf Programm-Ebene verwaltet und von den Product-Ownern auf Stories für die jeweiligen Teams heruntergebrochen. Bspw. alle fünf Iterationen (ca. 10 Wochen) wird ein Program Increment (PI) aus den einzelnen Inkrementen der Teams zusammengefasst und können, aber müssen nicht vom ART ausgeliefert werden. Features müssen in ein PI passen. Die Aufgabe der verschiedenen Rollen auf Programm-Ebene ist es, die Planung und die Lieferung der einzelnen Teile zu organisieren.
Program Increments sind die regelmäßige Kadenz des ART und sind vom eigentlichen Release zum Kunden getrennt, welcher auf anderer Terminbasis stattfinden kann.
Large Solution-Ebene
Für diejenigen, die an der Erschaffung der größten Hard- und Softwaresysteme der Welt beteiligt sind, gibt es die (optionale) Large Solution-Ebene. Die Large Solution-Ebene beinhaltet den Solution Train, Solution Intent, Solution-Management, Entwicklung und Architektur, agile Kunden- und Lieferantenbeziehungen sowie die Koordination des Wertestroms.
Portfolio-Ebene
Auf dieser Ebene werden die dem Portfolio zugehörigen Programme definiert. Programme sind aus dieser Sicht die Träger der Wertschöpfung des Portfolios und werden auf der Basis von Value Stream Mapping entdeckt und gegründet. Ein sehr großes Unternehmen hat typischerweise mehrere Portfolios mit deren jeweiligen Programmen und deren jeweiligen Teams. Aufgabe des Portfolios ist es, die Programme aus Überlegungen der Unternehmensstrategie und Investitionsabsichten mit Budget und Zielvorgaben (Epics) zu versorgen. Ein typisches Investment (Theme) hat eine Dauer von sechs bis zwölf Monaten, hier liegt jedoch im Gegensatz zu den darunter liegenden Leveln keine starre Kadenz vor.
Es wird zwischen Business Epics (kundenorientiert) und Enabler Epics (technische Lösungen) unterschieden. Epics werden in die Value-Stream-Ebene heruntergereicht und dort in Capabilities und anschließend in Features aufgeteilt.
Business und Architectural Epics werden parallel in einem Kanban-System gepflegt. Anhand von Metriken und Messungen des Flows auf dieser Ebene lässt sich der Prozess der kontinuierlichen Verbesserung (Kaizen) vorantreiben und über Work in Progress Limits eine optimale Kapazitätsnutzung einsteuern.