SAFe® Scaled Agile Framework 4.5 – Skalierung von Scrum
Scrum ist ein agiler Entwicklungsansatz für unterschiedlichste Produkte. Dies können Hardware, Software, Prozesse, Services und komplexe integrierte Systeme sein.
SAFe® ist neben Scrum of Scrums, Less – Large Scale Scrum, Nexus, Spotify oder das scrum@scale(TM) ein Framework für die skalierte agile Produktentwicklung. Solche Frameworks werden dann gebraucht, wenn es um umfangreiche und integrierte agile Produktentwicklungen geht bei der viele Entwickler und Teams beteiligt sind, die zusammenarbeiten, sich synchronisieren, sich ausrichten und die letztendlich liefern müssen.
Hintergrund zu SAFe®
SAFe® wurde von Dean Leffingwell und Kollegen, Scaled Agile Inc. entwickelt. Es ist ein agiles Framework, dass auf Lean aufbaut und die Möglichkeit bietet die gesamte Organisation agil einzubinden.
SAFe® ist neben Scrum-of-Scrums und LeSS das am meisten verbreitete agil skalierbare Framework, das häufig in großen Organisationen weltweit eingesetzt wird (in Deutschland u.a. bei Siemens, Bosch, Daimler). Laut 11th Annual State of Agile Survey3 by VersionOne finden viele der Befragten SAFe als populärste, führendste Skalierungsmethode und als “preferred method for scaling Agile” im Vergleich zu anderen Saklierungsmethoden.
Es steht auf einer Basis aus Lean-Agile Prinzipien, Iterative Entwicklung, Systems Thinking und Agile Product Development.
Das agile Manifesto1 wird von SAFe® in vollem Umfang unterstützt und durchgehend angewandt.
SAFe kennt selbst 9 zentrale Prinzipien für einen effektiven Entwicklungsfluss
#1 Beachte die Wirtschaftlichkeit (Take an economic view)
#2 Wende Systemdenken an (Apply systems thinking)
#3 Akzeptiere Variabilität und bewahre Optionen (Assume variability; preserve options)
#4 Entwickle inkrementell mit raschen integrierten Lernzyklen (Build in incrementally with fast, integrated learning cycles)
#5 Definiere Basismeilensteine auf Basis einer objektiven Einschätzung lauffähiger Systeme (Base Milestones on objective evaluation of working systems)
#6 Visualisiere und begrenze den Arbeitsvorrat in der Umsetzung, reduziere Losgrößen und manage die Länge von Warteschlangen (Visualize and limit WIP -Work in progress, reduce batch sizes and manage queue lengths
#7 Takte und synchronisiere organisationsübergreifende Planung (Apply cadence, synchronize with cross-domain planning)
#8 Erschließe die intrinsische Motivation von Wissensarbeitern (Unlock the intrinsic motivation of knowledge workers)
#9 Dezentralisiere Entscheidungen (Decentralize decision making)
Mehr dazu hier: Lesen Sie hier ab Seite 10ff im Whitepaper – SAFe® 4.5 Introduction2 was sich hinter den 9 SAFe-Prinzipien genauer verbirgt.
Funktionsweise von SAFe®
Hier die Übersicht zum Gesamtunfang von SAFe®
Abbildung Übersicht (Full Configuration) zu SAFe® . Quelle: https://www.scaledagileframework.com/
Die Abbildung zeigt den Gesamtumfang von SAFe® (Full Configuration) mit den Ebenen Portfolio, Large Solution, Program und Team. Wenn Sie dem Link folgen, gelangen Sie auf die Seite von scaledagilefrmework. Auf dem zunächst verwirrenden Bild mit vielen Symbolen ist jedes Icon anklickbar und bietet dadurch weitere umfassende Informationen zu dessen Hintergrund.
Betrachten wir uns zunächst die essenziellsten Ebenen Program und Team, die Basis von SAFe® . Sie beschreiben die kritischsten und erforderlichsten Elemente, welche den größten Benefit/Wertbeitrag des Frameworks realisieren. Alle anderen Ebenen bauen auf die Basis auf.
Abbildung Essential SAFe® - Basisebenen Program und Team
Quelle: Scaled Agile Inc., https://www.scaledagileframework.com/
Team - Ebene
Starten wir mit der untersten Ebene Team. Die Ebene Team folgt im Wesentlichen den Prinzipien und Werten, crossfunktionalen, selbstorganisierenden Teams, Teamgrößen und Vorgehensweisen von Scrum (alternativ Kanban oder Extreme Programming) und kennt die Rollen Scrum Master, Product Owner und Developer. Darüber hinaus finden sich weitere aus Scrum bereits bekannte Begrifflichkeiten u.a. Backlog mit NFRs (Non Functional Requirements), Kanban (z.B. Task Board), Story etc.
In dieser Ebene finden sich die einzelnen Sprints (Iterations) wieder, die bei SAFe® in der Regel jeweils auf eine Länge von 2 Wochen festgelegt sind und welche die jeweils in einen Sprint passenden Stories umsetzen. Dies entspricht einem Planungshorizont eines Deming-Zyklus (Plan-Do-Check-Adjust). Eingerahmt werden all diese Sprints wiederum durch eine Time Box von 8 – 12 Wochen (Cadence oder Kadenz: der Takt), dem Program Increment PI. Durch diesen regelmäßigen Takt (Develop on Cadence) wird die Wertschöpfung stabilisiert, besser plan- und messbar.
Programm Ebene
Die Ebene Programm enthält alle Rollen und Aktivitäten, die erforderlich sind um kontinuierlich Lösungen über den sogenannte Agile Release Train – ART (Continuous Delivery Pipeline) zu liefern. Der ART ist das eigentliche Backbone von SAFe und stellt das „Team von Teams“ dar, die als selbstorganisierte übergreifende Teamstruktur zu verstehen ist. Die Größe eines ART liegt zwischen 50 - 125 Personen und sollte 125 Personen nicht übersteigen. Größere Vorhaben erfordern dann einfach mehr ARTs
Vorteil dabei ist, dass die Ergebnisse bzw. Features der einzelnen Teams kontinuierlich integriert und getestet werden und nicht nur am Ende eines Program Increment. Damit ist der ART jederzeit lieferbereit!
Entsprechend der gemeinsamen Mission stimmen sich die Teams auf Basis des vorgegebenen PI – Takts ab und planen im PI Planning zu Beginn welche Features im aktuellen Program Increment geliefert werden können. Innerhalb des PI synchronisieren sich die Teams regelmäßig im Rhythmus der 2-Wochen Sprints mit Hilfe von Systemdemos. Am Ende des PI erfolgt ein Review-Meeting und ein allgemeines Inspect & Adapt I&A – Meeting, in der der bisherige Lösungsfortschritt des gesamten Release Trains demonstriert und bewertet wird. Die Sprint-Review Meetings auf Teamebene bleiben davon unberührt.
Auf dieser Ebene finden sich auch neue Rollen. So der System Architect/Engineer, das Product Management und der Release Train Engineer RTE.
Large Solution Ebene
Abbildung SAFe® – Large Solutionebene mit Basisebenen Program und Team. Quelle: Scaled Agile Inc., https://www.scaledagileframework.com/
Mehrere Agile Release Trains bilden einen Wertstrom ab, der zur „Solution“ beiträgt.
Zur übergeordneten Koordination mehrerer Programme bzw. Agile Release Trains dient der Solution Train. Mit Hilfe des Solution Trains werden ARTs auf die gemeinsame Vision und Mission ausgerichtet. Taktrate der einzelnen ART und ein gemeinsames Backlog werden synchronisiert. Der Solution Train ist für große und komplexe Lösungen geeignet.
Auf dieser Ebene weden auch wieder neue Rollen eingeführt. So finden sich hier die Rollen Solution Architekt/Engineer, Solution Management und Solution Train Engineer.
Portfolio Ebene
Mit dieser obersten Ebene gelangen wir wieder zum Ausgangsbild der Full SAFe® Configuration
Abbildung SAFe® – Full Configuration alle Ebenen – Fokus Portfolioebene. Quelle: Scaled Agile Inc., https://www.scaledagileframework.com/
Auf der Portfolio-Ebene wird entschieden an welchen strategischen Themen (Strategic Themes) entsprechend der strategischen Ausrichtung/Vision gearbeitet werden soll. Darüber hinaus geht es um Fragen des investment fundings (Lean Budgets) und lean governance. Basis dafür sind die Betrachtung der Wertströme (Value Streams).
Epics, als Teil der Wertströme (Value Streams) stellen dabei Container dar, die große Entwicklungslösungen umfassen, welche u.a. die Definition eines MVP – Minimal Viable Product und eine Budgetfreigabe vorab erfordern. Für die Weitergabe an einen Agile Release Train bzw. Program werden Epics weiter konkretisiert und in einzelne Features aufgeteilt. Auf Teamebene können diese Features, runtergebrochen auf Stories nun in die einzelnen Sprints übernommen werden.
Wie in den anderen Ebenen, gibt es auch hier wieder neue Rollen. Hier Epic Owners, Enterprise Architect und Lean Portfolio Management.
Einführung von SAFe®
SAFe ist eine Sammlung von erprobten Prinzipien und Praktiken für Lean, agile und DevOps. Es ist Baukastenorientiert und ermöglicht dadurch das selektieren des richtigen Elements im jeweiligen organisatorischen und unternehmensspezifischen Kontext.
Eines vorweg. SAFe® Full Configuration ist kein Blueprint für die 1:1 Umsetzung in der Organisation, auch wenn die Detailtiefe des Abbildung Full SAFe® Configuration das möglicherweise suggerieren mag. Vielmehr gilt es die richtigen Elemente aus dem Baukasten, die im jeweiligen organisatorischen und unternehmensspezifischen Kontext am besten passen, auszuwählen und einen für die Organisation passende individuellen Weg in der Anwendung von SAFe® zu finden.
Die Einführung kann nur in kleinen Schritte erfolgen und startet auf der Teamebene. Im zweiten Schritt bewegt man sich auf der Programmebene. Veränderung erfolgt als empirischer Prozess.
Lesen Sie hier ab Seite 24ff im Whitepaper – SAFe® 4.5 Introduction2 wie sich Scaled Agile Inc. eine Implementation Roadmap vorstellt.
Voraussetzungen
Die Einführung von SAFe® kann sich als komplexes Vorhaben, das eine starke Veränderungsbereitschaft auf allen Ebenen voraussetzt, erweisen.
Einem Zitat stimme ich jedoch vorbehaltlos zu:
„… Don't scale Scrum if you can't do Scrum well with ONE team …”, Mike Beedle
Pro / Contra von SAFe®
Pro
- Weltweit anerkanntes und von großen Unternehmen häufig genutztes agiles Framework. Gute Marktdurchdringung. Umfangreicher Support.
- Das Scaled Agile Framework unterstützt für große Entwicklungsorganisationen die Transformation in eine agile Organisation
- Auf Basis des Release Train Konstrukts besteht kontinuierliche Lieferbereitschaft
Contra
- Das Modell erschließt sich einem nicht auf Anhieb. Es erscheint komplex und zwingt die Betrachter und Beteiligten sich intensiv mit dem gesamten Modell auseinander zu setzen
- Kritisiert wird auch die starke top-down Orientierung und Inflexibilität
- Manche Begrifflichkeiten sind ohne eine intensive Auseinandersetzung mit dem Ansatz schwer nachzuvollziehen
Fazit
SAFe® ist ein mächtiges agiles Framework, dass sich für größere Unternehmen und große Vorhaben offensichtlich gut eignet. Der weltweite Verbreitungs- und Akzeptanzgrad in großen Unternehmen spricht für seine Durchsetzung im Markt.
Was auffällt sind die vielen Rollen, Ebenen, Meetings und Aktivitäten auf, die auch eine gewisse Gefahr und Risiko darstellen, dass dieses Framework unflexibel und schwerfällig werden kann. Ähnlich wie bei klassischen Prozessen.
Literaturhinweise, Interessante Links und Hinweise zu SAFe®
Website zu Scaled Agile Framework mit Erklärung der einzelnen Komponenten bei anklicken der Icons auf der Abbildung der Full SAFe® Configuration:
https://www.scaledagileframework.com/
1 Agiles Manifest
http://agilemanifesto.org/iso/de/manifesto.html
2 Whitepaper – SAFe® 4.5 Introduction, Overview of the Scaled Agile Framework® for Lean Enterprises, A Scaled Agile, Inc. White Paper, August 2017
https://www.scaledagile.com/resources/safe-whitepaper/
3 11th Annual State of Agile Report by VersionOne
https://content.cdntwrk.com/files/aT04MDg1NTEmdj0zJmlzc3VlTmFtZT12ZXJzaW9ub25lLTExdGgtYW5udWFsLXN0YXRlLW9mLWFnaWxlLXJlcG9ydCZjbWQ9ZCZzaWc9YTYyMWNiM2QwMDJiNTk0MTNjOTE4NDhmZjIyOGIzMDU%253D
Interessante Videos
What’s new in SAFe® 4.5
https://www.youtube.com/watch?v=2kHPIq6UGos
The ressource utilization trap, Henrik Kniberg, YouTube
