SAFe, movisco, agil, release, agile release train, scrum, scaled, scaled agile, scaled agile framework, value, Wert

SAFe® - Wohin fährt dieser Agile Release Train eigentlich?

Ich bin bei meinen Recherchen im Rahmen meines ersten großen nach SAFe® organisierten Projektes über folgende spannende Definition von SAFe® gestolpert: „SAFe® ist als Framework darauf ausgelegt, dass die richtigen Leute das Richtige zum richtigen Zeitpunkt richtig machen – ganz gleich, ob das jetzt 50 oder 5000 Leute sind, oder ob das jetzt in der Entwicklung, im operativen Management oder im strategischen Management passiert." Diese Definition hat mich neugierig gemacht und ich habe mich näher mit diesem skalierten agilen Vorgehen und dem darin Richtung Ziel fahrenden Agile Release Train (ART) beschäftigt.

Im Zentrum eines nach SAFe® organisierten Projektes oder eines „Lean Enterprise“ steht dieser sogenannte Agile Release Train, welcher den Projektfortschritt in Form eines Zuges versinnbildlicht. Aber wohin fährt er denn eigentlich und wer steuert ihn?

Wohin fährt der Agile Release Train?

Agile Projekte bzw. Transitionen von Unternehmen hin zu agilem Projektmanagement starten oft bei wenigen kleinen agilen Teams, die sich darauf konzentrieren, ihren Beitrag zum großen Ganzen zu leisten. Um diese individuellen Ergebnisse besser zu vereinen und zu steuern, wird auf Unternehmens- oder Programmebene gerne das Scaled Agile Framework SAFe® eingesetzt und die Teams zu sogenannten Agile Release Trains zusammengefasst, die auf ein gemeinsames Ziel ausgerichtet sind.

Wer in Agile Release Trains (ART) organisiert ist, kann das Potential aller Teammitglieder besser ausschöpfen und das Produkt wertorientiert entwickeln.

Individuell durch Parameter

Aber wohin fährt dieser ART nun wirklich? Nun, im Grunde fährt er seinem Projektziel entgegen. Dazwischen erreicht er einige Zwischenstationen, die sogenannten Program Increments (PI). Wichtig ist, dass der Zug immer in Bewegung ist und dabei Ergebnisse erzeugt. Dies wird sichergestellt durch:

Continuous Exploration –
Definition einer Vision, Roadmap und Solution-Feature-Set, um Markt- und Kundenanforderungen ständig zu evaluieren.
Continuous Integration –
Ständige Implementierung von Product Backlog Items durch Entwicklung, Test und Integration dieser Module in einer Integrations- oder Stagingumgebung.
Continuous Deployment –
Übernahme integrierter und validierter Module von der Integrations- / Stagingumgebung in die Produktionsumgebung, um sie dort zu testen und auf das Release vorzubereiten.

Zusammenfassend lässt sich dies so erklären:

Basierend auf einem zentralen Program-Backlog werden in den einzelnen agilen Teams kontinuierlich Weiterentwicklungen erarbeitet, in den Agile Release Train integriert und regelmäßig in die produktive Umgebung veröffentlicht. Man spricht von einem „Release on Demand“ oder auch:

Making value available when it’s needed

Wer steuert den Agile Release Train?

Der größte Unterschied zu einem agilen Vorgehen, wie wir es von SCRUM kennen, dargestellt im Blogbeitrag „Scrum – Was wir vom Rugby lernen können“ ist, dass im Scaled Agile Framework SAFe® nicht nur einzelne agile (Scrum-)Teams das Produkt erarbeiten, sondern im Agile Release Train viele einzelne agile (Scrum-)Teams organisiert sind und in Summe an einem wesentlich größeren oder langfristigeren Ziel arbeiten. Teams von 100 Personen sind dabei keine Seltenheit.

Der Agile Release Train (ART) ist eine Vereinigung verschiedener agiler Teams, die auf Dauer angelegt ist und zusammen mit ihren Stakeholdern inkrementell ein Produkt entwickelt und bereitstellt.

Somit ist neben den Product Ownern, die die einzelnen agilen Teams steuern, eine zentrale Rolle notwendig, um den ART zu steuern. Dies ist der sogenannte RTE, der „Release Train Engineer“. Diesen werden wir im Folgenden bei den Rollen noch genauer kennenlernen

Hinter der Frequenz der Produktivsetzungen steht ein strukturierter Releaseplan, der die Vision und die festgelegte Roadmap der Lösung unterstützen soll und in Haltestellen, die sogenannten Program Increments „PI“, getaktet ist.

Vor dem Start eines PI steht ein aufwendiger PI-Planning-Workshop, der durch SAFe® exakt auf eine Dauer von zwei Tagen mit einer festgelegten Agenda definiert ist. Teilnehmer sind alle (!) Projektmitarbeiter sowie die Stakeholder. Erzielt wird durch diesen zeit- und kostenintensiven Prozess ein zwischen allen Beteiligten abgestimmtes PI mit einem von den Umsetzungsteams geplant realisierbaren und einem von den Stakeholdern bestätigten akzeptierten Umfang.

Die Agenda des PI-Planning ist dabei wie folgt vorgegeben:

	Day 1	Day 2
08:00 – 9:00	Business Context	Planning adjustments	08:00 – 9:00
09:00 – 10:30	Product/Solution Vision	Team breakouts	09:00 – 11:00
10:30 – 11:30	Architecture Vision and development practices	Final plan review and lunch	11:00 – 13:00
11:30 – 13:00	Planning context and lunch	Program risks	13:00 – 14:00
13:00 – 16:00	Team breakouts	PI confidence vote	14:00 – 14:15
16:00 – 17:00	Draft plan review	Plan rework if necessary	14:15 – ?
17:00 – 18:00	Management review and problem solving	Planning retrospective and moving forward	After Commitment

Flow of Value

Auch große Ziele erreicht man in kleinen Schritten. Ein Grundsatz von SAFe® ist die Wertorientierung der Lösung, d.h., nicht das Projekt und seine Durchführung ist die Messgröße, sondern ausschließlich der dabei erzeugte Wert. Der Agile Release Train hilft dabei, diesen Wert mit seinen PI’s in kleinen Schritten zu liefern. SAFe® organisiert dazu den ART rund um den sogenannten „Flow of Value“.

Working Software is the primary measure of progress

Agile Manifesto Principle 7

Dazu kann es notwendig sein, Projektteams mit unterschiedlichen Ausrichtungen zu etablieren, um den höchstmöglichen Wertschöpfungsfluss zu erzeugen:

Stream-aligned Teams –
interdisziplinär aufgestellt und auf den originären „Flow of Value“ ausgerichtet. Diese Teams erzeugen den eigentlichen Wert der Lösung.
Complicated Subsystem Team –
Spezialistenteams, die für die Erzielung eines speziellen Ziels tiefe Spezialistenkenntnisse und Erfahrung benötigen.
Platform Teams –
bereiten Services und Plattformen auf, die die anderen Teams wiederum in deren Arbeit unterstützen (z.B. Kollaborationssoftware, IT-Systeme, etc.).
Enabling Teams –
werden benötigt, um andere Teams mit speziellen Kenntnissen und notwendigen Fähigkeiten auszustatten („to ramp up“).

Rollen des Agile Release Train nach SAFe®

Den ART zu steuern erfordert eine übergreifende Sicht auf den „Flow of Value“ sowie die einzelnen Teams. Dies wird zentral vom RTE gesteuert, der jedoch von weiteren Teams Unterstützung erfährt.

Insgesamt erfordert ein SAFe® Projekt neben den Projektteams die folgenden Rollen:

Release Train Engineer –
Hält das agile Projekt als quasi Chief Scrum Master zusammen und führt den ART von Haltestelle zu Haltestelle (von PI zu PI).
System Architect / Engineering –
Liefert Unterstützung in allen architektonischen und technischen Fragestellungen und unterstützt die Teams im Train.
Business Owners –
Die Key Stakeholder als die wesentlichste Interessengemeinschaft des agilen Release Trains definieren den Nutzen der Lösung.
Product Management –
Verantworten, definieren und priorisieren die Ziele des Release Trains, das Product Backlog.
System Team –
Unterstützen mit Prozessen und Tools um die erzeugten Produktinkremente früh und regelmäßig zu veröffentlichen. Das System Team stellt sicher, dass die eigentlichen Projektteams des ART nicht mit Deploymentaufgaben ausgebremst werden und ein regelmäßiger Flow erzeugt wird.

Early delivery has higher value

SAFe® Lean-Agile Principle 1 “Take an economic view”

Fazit: und wohin fahren Sie Ihren Agile Release Train?

Die Erfahrung aus dem SAFe® Projekt zeigt, dass der Agile Release Train helfen kann, sich einem großen, weit entfernten Ziel in vielen Zwischenetappen anzunähern und dabei die Richtung und die Details immer wieder korrigieren zu können, ganz egal wie lang und schwer der Weg dahin auch ist.

Die regelmäßigen PI’s sichern vor allem den Nutzen, der gemäß dem „Flow of Value“ nach SAFe® das relevanteste Ziel darstellt.

Wenn Sie daran interessiert sind und von unseren Erfahrungen aus diesem sowie zahlreichen anderen Projekten nach Scrum oder anderen Vorgehensarten profitieren wollen, sprechen Sie uns hierzu gerne an: Robert Meinl und Michael Junklewitz.

Tipp:

Besuchen Sie uns regelmäßig hier im Blog, um auch weitere Details zu SAFe® und andere agilen und klassischen Vorgehensmodellen zu erfahren, wie z.B.

SCRUM – Was wir vom Rugby lernen können weiterlesen
Scrum hautnah – was steht auf Ihrer Bucketlist? weiterlesen

Über den Autor

Robert Meinl

Robert Meinl ist Expert Consultant bei der movisco AG im Bereich IT Consulting und verfügt über eine langjährige Berufserfahrung in der Beratung von Banken. Er besitzt ein Diplom in Wirtschaftsinformatik. Die IT-Expertise von Robert Meinl umfasst Planung, Einführung, Migration und Wartung von SAP Lösungen im Bankenumfeld. Seine Kernkompetenzen liegen in den analytischen SAP Lösungen SAP FRDP und Bank Analyzer mit SDL und CRA sowie dem SAP BW. Fachexpertise hat Robert Meinl vor allem in Bankprodukten, regulatorischen Anforderungen sowie Accounting im Bereich der Umsetzung von Reporting-Anforderungen in die Prozess- und IT Landschaft von Banken, das Management von Implementierungsprojekten in den Bereichen Bilanzierung und Risikomanagement sowie die Optimierung der Risikodatenaggregation.