SAfe 4.5 ist im Juni freigegeben worden und bringt einige neue Features.
Manche sind kosmetischer Art, aber es gibt auch wichtige Erweiterungen und Klarstellungen.
Neue Delivery Pipeline
Die wohl wichtigste Erweiterung ist die Delivery Pipeline.
Sie baut nach wie vor auf dem Mantra „Develop on Cadence, Release on Demand“ auf, mit dem sichergestellt werden soll, dass das System jederzeit lieferfähig ist.
Offenbar wurde das aber bisher nicht in jeder Implementierung erfolgreich umgesetzt, so dass jetzt sehr viel Sorgfalt in die detaillierte Beschreibung fließt, wie eine erfolgreiche Pipeline aussehen muss.
Die Beschreibungselemente sind
- Continuous Exploration, wo sichergestellt werden soll, dass regelmäßig neue Anforderungen des Marktes und der Kunden betrachtet werden und dass in Kooperation mit Kunden und anderen Stakeholdern neue Epic bzw. Features gefunden werden
- Continuous Deployment, die Infrastruktur, die sicherstellt, dass neue Feature auch zuverlässig, in hoher Qualität und in kleinen Inkrementen bis in eine Staging-Umgebung geliefert werden können.
- Continuous Delivery beschreibt, was nötig ist, wie die Features in die Staging- und Produktionsumgebungen geliefert werden können, damit man jederzeit liefern kann. Dies wird jetzt deutlicher als bisher von den Releasezyklen getrennt, die von externen Marktanforderungen, von strategischen Entscheidungen, Compliance-Freigaben und von vielem mehr beeinflusst werden können.
Integration von Lean Startup-Strategien
Nicht weniger wichtig ist die Integration von Ideen aus dem Lean Startup, mit der das Problem angegangen wird, dass der Fluss von Epics durch das Gdesamtsystem sehr linear aussah.
Vor allem in der Explorationsphase wird deutlich, dass die Beschreibung jetzz wesentlich iterativer als bisher ist. SAFe bezieht sich auf Lean Startup Strategien und das Lean UX Modell. Das heisst, dass ein Epic keinen Business-Case mehr bekommt, sondern eine Hypothese. Diese wird in einer ersten Version bis zur Marktreife entwickelt (als MMF, minimal marketable feature), dann wird entschieden, ob und wie oft weitere Versionen / Erweiterungen entwickelt werden. Dadurch kann der endgültige Umfang deutlich von der ursprünglichen Planung abweichen und es wird ein expliziter Lernzyklus in die Entwicklung eines Epic eingebaut – manche Epics werden dadurch auch nie fertig, sondern werden kontinuierlich weitgerentwickelt.
DevOps als Kultur- Organisations- und technische Aufgabe
DevOps wird als primär als organisatorische und kulturelle Aufgabe beschrieben: der wichtigste Punkt ist das Aufbrechen traditioneller Silos (Entwickler, Tester, etc.) in crossfunktionale Teams, die gemeinsam eine häufige Lieferung neuer Funktionalität sicherstellen können. Erst auf dieser Grundlage können die Werkzeugketten (die dann aber auch nötig sind) Wirksamkeit entfalten.
Die Einführungsstrategie ist konkreter geworden
Bei der Einführung werden wesentlich deutlicher die Erfolgsbedingungen und die Rollen bei einer SAFe Implementierung genannt als bisher.
Viele kleine Änderungen
- Das Big Picture wird weniger komplex. Das Big Picture ist bereinigt worden und übersichtlicher geworden: zu viele Details drohten die Übersichtlichkeit zu gefährden. Das gilt umso mehr, als im Laufe der Zeit immer mehr Informationen dazugekommen sind. Dazu gehört auch das Herauslösen der verschiedenen optionalen Rollen in die Randleiste, die Spanning Paleete – es wir so zu einen klarer, dass z.B. Das Systemteam je nach Bedarf auf verschiedenen Ebenen angesiedelt werden kann. Pro Konfiguration werden auch verschiedene Rollen angeboten, was Erfahrungen aus verschiedenen Anwendungen repräsentiert.
- Neue Konfigurationen. Die SAFe-Konfigurationen sind überarbeitet worden, um den Aufwand zur Anpassung zu reduzieren und sie zielgerichteter auf Anwendergruppen zuzuschneiden.
- Umbenennungen. Verschiedene Umbenennungen sollen Quellen für Missverständnisse beseitigen. Die wichtigsten sind
• Die Value Stream Ebene heisst jetzt Solution-Ebene, insbesondere gibt es jetzt den Solution Train, einen Train of Agile Release Trains
• Das Budget-Verfahren heisst jetzt Lean Budgeting
• SAFe bekommt einen neuen Namen – es heisst jetzt „SAFe for Lean Enterprises“ – damit soll auch ein erweierter Anspruch für die Enwicklung komplexer „Systeme von Systemen“, etwa aus Hardware- und Softwarekomponenten formuliert werden.
