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.
