Ende Juli hat Scaled Agile, Inc die neue Version 3.0 ihres Scaled Agile Frameworks für skalierbare Agilität im Großen freigegeben. Das entsprechend aktualisierte Big Picture findet sich auf unserer Seite zum Scaled Agile Framework im Methodenbereich sowie als interaktive Grafik auf der offiziellen Webpräsenz.

Die Änderungen im Überblick

Neben Aktualisierungen für fast alle Beschreibungen des Rahmenwerks für mehr Klarheit wurden einige signifikante Änderungen durchgeführt. Die Programm-Ebene wurde aufgeräumt und um einige Details ergänzt und die Portfolio-Ebene in ihrer Darstellung im Big Picture angepasst:

SAFe-3.0-8.5x11_print

Wem SAFe bereits ein Begriff ist, dem fallen mit Sicherheit einige der Änderungen sofort auf, aber andere werden vielleicht nicht sofort ersichtlich – wir führen durch alle Änderungen in der neuen Version.

Das Team-Level bleibt überwiegend unverändert, lediglich drei Praktiken aus dem Bereich Codequalität wurden ins Big Picture eingefügt:

Dies hebt die Wichtigkeit dieser Praktiken für die agile Entwicklung hervor.

Aufräumarbeiten auf der Programm-Ebene

Als prominenteste Änderung fällt ins Auge, dass Potentially Shippable Increments durch Program Increments ersetzt wurden. Da die Veröffentlichung zum Kunden getrennt auf anderer Terminbasis stattfinden kann und nicht an eine Entwicklungs-Kadenz gebunden ist, wurden PSIs zur Verdeutlichung dieser Trennung in Program Increments (PI) umbenannt.

SAFe-3.0-Program

Diese Namensänderung macht das Konzept hinter PIs eindeutiger, kann durch die Nähe zur vorigen Bezeichnung jedoch verwirren.

Metriken werden klarer getrennt
Im Big Picture werden ART-Metriken und Portfolio-Metriken nun sauber getrennt dargestellt, während sie zuvor auf Portfolio-Ebene zusammengefasst wurden.

Program Epics als neues Konzept
Die neuen Program Epics gliedern sich zwischen Business Epics und Features ein. Features stellen Funktionalität in einem Programm dar, welche von einem Agile Release Train innerhalb eines Program Increments erledigt werden können. Business Epics stellen grobe Anforderungen auf Portfolio-Ebene dar, welche PI- und ART-umfassend sein können. Falls jedoch ein ART Produktmanager ein Business Epic für einen Train formuliert, welche mehrere PIs zur Fertigstellung benötigt, gab es bisher ein Problem – es gab keine Möglichkeit die einzelnen Features nochmals zu gruppieren, was der Übersicht hinderlich war. Es war nicht sofort ersichtlich, welches Feature in welchem ART in welchem PI läuft. Die neuen Program Epics stellen eine neue Hierarchie-Ebene dar und ermöglichen es Produktmanagern, diese langlebigen umfangreichen Anforderungen besser zu überblicken, egal aus welchem Portfolio sie stammen.

Weitere Änderungen

  • HIP-Iterationen werden zu IP-Iterationen und die Formulierung Hardening fällt weg; die Aktivitäten rund um Validierung sind auch Teil des Release Objects, da hier ebenfalls bestimmt werden muss, ob eine Veröffentlichung stattfinden kann oder nicht.
  • Das Release Object beschreibt, wie ein Release in einer SAFe-Umgebung abläuft und die entsprechenden Tätigkeiten auflistet, denn SAFe trennt klar zwischen Entwicklungs- und Veröffentlichungs-Kadenzen.
  • Shared Resources aus SAFe 2.0 wurden wieder eingeführt. Shared Resources werden zentral verwaltet und stellen Rollen dar, welche nicht einem ART dediziert zugeordnet werden können, z.B. Konfigurationsmanagement oder Scrum Coaches.
  • Das KG-Symbol wurde durch das WSJF-Symbol ersetzt, da Weighted Shortest Job First SAFe-Praktikern eher ein Begriff sein sollte.

Alles in allem wirkt die Programm-Ebene somit aufgeräumter und ist weitaus besser verständlich – Grundkenntnisse in SAFe vorausgesetzt.

Mehr Flow für die Portfolio-Ebene

Die Portfolio-Ebene hat die umfangreichsten Änderungen erfahren und die Big Picture-Grafik stellt den Fluss eines Program Portfolios nun aussagekräftiger als zuvor dar.

SAFe-3.0-Portfolio

Es wird deutlicher, dass ein Program Portfolio aus einem oder mehreren Werteströmen (Value Steams) zusammengesetzt ist und Produkte an den Markt bringt.

Neue Guidance zur Koordination mehrerer Agile Release Trains für einen Value Stream
Jeder Wertestrom ist, abhängig von seiner Größe, aus einem oder mehreren Agile Release Trains zusammengesetzt; falls eine Wertschöpfungskette mehr als 125 Menschen umfasst, muss diese in mehrere ARTs aufgeteilt werden. Der Artikel zum Thema ART coordination stellt dar, wie die Koordination mehrerer ARTs, die einen Wertstrom beliefern, funktioniert und unter Umständen zusätzliche Rollen benötigt.

Budgets klarer dargestellt
Die restliche Grafik stellt den Fluss, begonnen mit Strategic Themes, als Vision des Program Portfolio verbunden mit der Marktstrategie des Unternehmens dar. Ziele beeinflussen die Entscheidungen für die Budgetierung von ARTs bis herunter auf deren Roadmaps. Da SAFe Budgets an ARTs direkt verteilt, haben diese Trains eine gesicherte Finanzierung über einen längeren Zeitraum hinweg, was Management und Entwicklern mehr Freiheit gibt.

Ein gewisser Teil des Budgets ist für ART-übergreifende Initiativen reserviert, welche mit Epics im Portfolio Backlog umgesetzt werden. Das unterscheidet sich nicht von SAFe Version 2.5, jedoch macht SAFe 3.0 deutlich, das der Großteil des Budgets direkt an ARTs geht und nicht durch das Portfolio Backlog fließt.

Lean-Agile Leaders wichtiger denn je
Die zentrale Rolle, welche Lean-Agile Leaders in Portfolio- und Programm-Ebene spielen, wurde im Big Picture hervorgehoben sowie vier Prinzipien als Leitsätze für Lean-Agile Leaders formuliert:

  • Eine Sicht auf das System einnehmen (Take a systems view)
  • Das Agile Manifest leben (Embrace the Agile Manifesto)
  • Einen Fluss für die Produktentwicklung einführen (Implement product development flow)
  • Die intrinsische Motivation von Wissensarbeitern entfachen (Unlock intrinsic motivation of knowledge workers)

Diese Rolle gab es bereits in Version 2.5, jedoch macht SAFe 3.0 deutlich, wie kritisch diese Rolle im Gesamtkontext ist: Lean-Agile Leaders stellen die Leitfiguren für die agile Veränderung dar, sie lehren und leben die postulierten Denkweisen und Praktiken und gehen somit mit gutem Beispiel voran.

Quellen & Verweise

  • Offizielle Scaled Agile Framework Webseite
  • Lean Samurai – SAFe 3.0 Changelog