SAFe

Der Weg einer Business-Anforderung durch das Scaled Agile Framework

Das Scaled Agile Framework® von Dean Leffingwell ist eine Best Practices-Sammlung um Agilität auf die Entwicklung eines umfangreichen Produkts oder einer Produktgruppe (Value Stream) zu skalieren. Das Framework ist frei zugänglich und wird stetig weiterentwickelt. Darüber hinaus sind die Ansätze und Methoden bereits mehrfach in der Realität erprobt. Beim Einsatz im eigenen Unternehmen sind spezifische Anpassungen aber zwingend notwendig. Diese sollten jedoch kritisch hinterfragt und die SAFe®-Best Practices genau betrachtet werden.
In diesem Blog wollen wir den Weg einer Business-Anforderung bis zur Umsetzungstask nach SAFe®-Best-Practice genauer betrachten. Dazu sehen wir uns die drei Ebenen des Scaled Agile Frameworks® sowie die dazugehörigen Backlogs an.


Step 1: New => Portfolio Backlog
Auf dem Portfolio Level werden Business- und Architektur-Anforderungen in einem Portfolio-Kanban-Prozess ausgearbeitet und bewertet. Während der Ausarbeitung wird kontinuierlich geprüft, ob eine weitere Bearbeitung sinnvoll erscheint. Das Ergebnis dieses Prozesses ist pro Epic (Business/Architectural) ein „Lightweight Business Case“, der zur weiteren Bearbeitung in das Portfolio Backlog gereiht wird. Letzteres ist eine geordnete Liste von Epics, die zur Umsetzung vorgeschlagen sind. Der „Lightweight Business Case“ enthält Aussagen zu Kosten/Nutzen, fachl. Motivation, Risiken bei Nichtumsetzung u.v.m.


Step 2: Portfolio Backlog => Program Backlog
Wenn ein Epic aus dem Portfolio Backlog zur Umsetzung ausgewählt wird, zerteilt der Epic Owner in Zusammenarbeit mit dem Product Management das Epic nach fachlichen Kriterien in Features. Ein Feature besteht aus einem Titel und einer knappen Beschreibung des Ziels. Darüber hinaus ist ein Feature grob geschätzt, gewichtet/priorisiert und durch Akzeptanzkriterien näher beschrieben. Die erstellten Features werden in das Program Backlog sortiert nach Gewichtung abgelegt. Zur Umsetzung ausgewählte Features sind der Input für das Release-Planungsmeeting.


Step 3: Program Backlog => Team Backlog
In dem zweitägigen Release-Planungsmeeting werden die ausgewählten Features an die agilen Teams (PO, SM, Dev-Team) verteilt. Aus den zugeordneten Features entwickelt jedes Team die umzusetzenden User Stories. Diese werden geschätzt und für die Umsetzungsiterationen des nächsten Agile Release Trains eingeplant. Nötige Zuarbeiten anderer Teams werden über einer Abhängigkeitsmatrix kartiert. Die erstellten Stories landen damit in den jeweiligen Team Backlogs.
Exkurs: Das Release Planning ist also mehr als ein reines Planungsmeeting => Es wird inhaltlich gearbeitet!
Das Ergebnis des Release-Planungsmeeting sind ca. 4 geplante Sprints. Planungsgenauigkeiten für Sprints, die weiter in der Zukunft liegen, werden durch eine geringere (Plan-)Auslastung berücksichtigt.


Step 4: Team Backlog => Iteration Planning
Auf dem Team-Level wird zu Beginn jeder Iteration vom Team ein Iteration Planning durchgeführt. Inhalt ist die Überprüfung des erstellten Plans (aus dem Release Planning) und das Ableiten von Umsetzungstasks aus den eingeplanten User Stories. Daraufhin beginnt die Implementierung der Anforderungen.


Soweit die Theorie, …
aber wie bilde ich das in meinem Unternehmen ab?


In der Realität habe ich noch keine SAFe®-Implementierung gesehen, die diese Arbeitsschritte genau abbildet. Die zwei größten Unstimmigkeiten sind meistens die Implementierung der Portfolio-Ebene und die Frage „Wie muss der Input für das Release Planning idealerweise vorbereitet sein?“.
Besonders die unternehmensspezifische Antwort auf die letzte Fragestellung lässt erkennen, wie weit das Unternehmen auf dem Weg zu einer agilen Organisation ist.

Eine plausible Antwort wäre:
„Da es ein sehr teures Event ist, bereiten wir die Inhalte detailliert vor. Am besten wir erstellen bereits im Vorfeld die User Stories und verteilen Sie an die Teammitglieder, die sie idealerweise umsetzen. So können sich die Teilnehmer auf das konzentrieren, was Sie betrifft (und vielleicht schaffen wir es dann auch in einem statt in zwei Tagen).“


Eine reifere und nach dem Scaled Agile Framework® angestrebte Antwort könnte so klingen:
„Wir bereiten die Infrastruktur des Events so vor, dass die Teams während der Veranstaltung möglichst ohne Einschränkung arbeiten können. Wir wählen im Vorfeld die wichtigsten Features aus und lassen diese durch die Teams ausarbeiten. Falls während des Meetings klar wird, dass wir mehr schaffen können, liefern wir Features nach. Die Product Owner kennen das Ziel ihrer Features und versuchen es mit den Teams in User Stories umzusetzen. Am Ende der zwei Tage sollten alle Beteiligten wissen, wann sie die nächsten 4 Sprints machen und warum sie es tun.“
Mit dem Blog und den dargestellten zwei Antwortmöglichkeiten will ich verdeutlichen, dass das Scaled Agile Framework® nur einen – m.M.n. gut durchdachten – Rahmen zur Verfügung stellt. In diesem Rahmen kann eine agile Organisation wachsen. Das Scaled Agile Framework® ist jedoch keine Blaupause oder Handlungsanweisung, der man zum Erfolg nur folgen muss.

Kommentare (12)

Leon Seipp

Leon Seipp

am 10.08.2018
Dies ist ein Test.

Peter

Peter

am 14.08.2018
Richtig, das sehe ich auch so!

Lara Hieß

Lara Hieß

am 13.08.2018
Ein weiterer Test-Kommentar!

Lara

Lara

am 14.08.2018
Dies ist ein Test

Test

Test

am 21.09.2018
test

Stefan Hermanns

Stefan Hermanns

am 26.06.2019
Es war wirklich ein super Event... fast ja schon historisch ;-)
Ich hoffe das restliche Feedback deckt sich mit dem und es kommt zu einem regelmässigen Format. Ich halte es für unheimlich wichtig im Raum DACH hier dieses Forum zu etablieren.
Danke für die super Orga!

Matthias Opitz

Matthias Opitz

am 26.06.2019
Die Einschätzung von Stefan kann ich nur bestätigen.
Es war wirklich eine tolle Veranstaltung mit vielen erfahrenen RTEs. Es gab jede Menge Themen und Fragen , so dass man in jedem Zeitslot die Qual der Wahl hatte.
Ich freue mich, wenn es auch im nächsten Jahr wieder ein solches RTE BarCamp gibt.
Danke an alle die dieses Event organisiert und möglich gemacht haben - aber auch an alle Teilnehmer!

Rich Tavilla

Rich Tavilla

am 20.05.2020
Thanks for sharing our lessons learned. Did you participants have their video cameras on? What did you do to suggest they attend with video on?

Rich Tavilla

Rich Tavilla

am 20.05.2020
...your lessons learned :-)

Kurt Jäger

Kurt Jäger

am 05.08.2020
Hallo Manuel,
danke für den schönen Artikel, in dieser Woche hat Mark Rix von der SAI einen weiteren Kurs vorgestellt der demnächst veröffentlicht wird. Dort wird eine Brücke zwischen DevOps und SAFe4Architects gebaut. Also ausgehend von der Continous Delivery Pipeline die technischen Aspekte behandelt, die ein architekt mit seinem System Team angehen sollte um Pipeline zu automatisieren und damit die LeadTime signifikant zu reduzieren. Artikel hierzu sind z.B.:
https://www.scaledagileframework.com/blog/accelerating-flow-with-devsecops-and-the-software-factory/
https://www.scaledagileframework.com/accelerating-flow-with-devsecops-and-the-software-factory/
sowie das Youtube video https://youtu.be/2EIHiXFb8tY was die Grundlage für das neue Training werden soll. Stay SAFe and Deliver fast Kurt

Program

Program

am 11.02.2021
"So ist das Wort „Program“ endlich nicht mehr auf dem Big Picture zu finden"
Ich sehe das "Program Backlog" in v5.1 nach wie vor unter https://www.scaledagileframework.com/# (abgefragt am 11.2.2021).

Felix Rüssel

Felix Rüssel

am 11.02.2021
Ja, das stimmt. Es ist jetzt "weniger Program" zu finden aber z.B. beim "Program Backlog" (hey, warum nicht "ART Backlog"??) und in diversen Guidance Artikeln (z.B. zu Vision) wird noch "Program" benutzt.

Ist eben ein iteratives, inkrementelles Vorgehen :-).
Neuen Kommentar schreiben