Besonderheiten der Arbeit eines Agile-Teams in SAFe im Vergleich zu Scrum in der Praxis

Nach der Veröffentlichung unter Freunden des ersten Artikels über Burn Down Chart, war die erste Frage, die in den Kommentaren gestellt wurde: "Es wäre interessant, mehr über eure Erfahrung mit SAFe zu erfahren". Daher werde ich in diesem Artikel versuchen, die Besonderheiten der Arbeit in SAFe gegenüber Scrum in unserer Praxis darzulegen. Ich erhebe keinesfalls Anspruch auf die absolute Wahrheit und freue mich über jegliche Korrekturen und Präzisierungen von Kollegen.

Zunächst zähle ich thesenartig das Wichtigste auf, was meiner Meinung nach die Arbeit in SAFe von SCRUM unterscheidet.

• Increment in Scrum und Program Increment in SAFe
• ART - Agile Release Train
• Anzahl der zusammenarbeitenden Teams
• PIPE
• SOS
• PO - kein Eigentümer des Geschäfts
• RTE
• Der fünfte Sprint für die Schulung
• System Demo

Increment in Scrum und Program Increment in SAFe. Tatsächlich sind es unterschiedliche Begriffe, aber man kann leicht durcheinanderkommen, da bei uns niemand den Begriff Program Increment verwendet, alle sagen einfach Increment - und das ist bereits ein anderer Begriff, der in SCRUM verwendet wird. Aber im Großen und Ganzen sind sie meiner Meinung nach vom Sinn her recht ähnlich. Increment in SCRUM - das ist im Wesentlichen das aktuelle Produkt + die für den Sprint geplanten Stories im erledigten Zustand (die DOD des Teams bestanden haben). Program Increment - das ist das Zeitintervall, in dem der Zug (Agile Release Train) den inkrementellen Wert in die Produktion liefert. Von der Dauer her sind das bei uns 4 Sprints à 2 Wochen für die Entwicklung und ein Sprint für die Schulung.

Agile Release Train - das ist ein Team von Teams, die an einem einzigen Wertstrom arbeiten. Wir nennen das einfach Zug, aber laut Framework sollte man es korrekt "Solution" nennen. In unserem Fall wird diese Regel nicht vollständig eingehalten und die Teams arbeiten oft aus technischer Sicht an verschiedenen Produkten, da die meisten Business-Features komplex umgesetzt werden und mehrere Produkte betreffen. Das ist die technische Seite. Aber ich bin sicher, dass jemand alle IT-Systeme als ein Produkt des Unternehmens betrachtet und das vielleicht sogar richtiger ist.

Anzahl der zusammenarbeitenden Teams ist bei uns in SAFe deutlich größer, insgesamt werden bis zu 125 Personen in einem Zug empfohlen. Wir haben 3 Züge und nicht in jedem wird diese Regel eingehalten, es gibt Züge mit mehr als 125 Personen. SCRUM beschreibt nicht, wie man mit anderen Teams interagiert, soweit mir bekannt ist, im Gegensatz zu SAFe, wo es sehr klare Empfehlungen dazu gibt. Das meiner Meinung nach auffälligste Artefakt dafür ist das Program Board.

Darauf werden die Wechselbeziehungen zwischen den Teams des Zugs dargestellt, und bei der Diskussion darüber finden bei uns die wöchentlichen Veranstaltungen Scrum Of Scrums (SOS) statt.

Etwa alle 2,5 Monate (alle 5 Sprints) findet das Ereignis PIPE - Programm Increment Planning Event. Das ist, wenn alle verteilten Teams sich für 2 Tage in einem Saal versammeln und ihre Arbeiten für die nächsten 2,5 Monate planen. Im Verlauf dieser Veranstaltung entstehen Artefakte wie das Program Board, zum Beispiel, auf dem alle Abhängigkeiten der Teams untereinander für jeden der Züge dargestellt werden, oben habe ich bereits gezeigt, wie es aussieht. Die Aufgabe des Scrum Masters jedes Teams bei dieser Veranstaltung ist die Moderation der Ermittlung einer maximalen Anzahl von Abhängigkeiten, dann nach Möglichkeit deren Beseitigung (durch mündliche Weitergabe von Kompetenzen, zum Beispiel, von Team zu Team oder durch Übernahme einer Abhängigkeit von einem Team in ein anderes, damit das Team sein Feature autonom umsetzen kann, ohne von jemandem abhängig zu sein). In der Praxis geschieht das bei uns genau so. Zuerst werden die Features in User Story zerlegt, die User Stories auf 4 Sprints verteilt. Die Features werden auf dem Program Board platziert und die Abhängigkeiten von anderen Teams, die es gibt, eingetragen. Im Verlauf der Veranstaltung wird das diskutiert und korrigiert.

SOS - Scrum Of Scrum. Diese Veranstaltung findet einmal pro Woche für jeden Zug separat statt. Die Scrum Master aller Teams des Zugs versammeln sich online, das Program Board des Zugs wird übertragen und die Status aller Abhängigkeiten und Features der Teams des jeweiligen Zugs werden besprochen. Im Wesentlichen ist diese Veranstaltung für die zentralisierte Synchronisierung der Teams innerhalb des Zugs notwendig. So etwas wie ein Standup, aber einmal pro Woche und nicht für das Team, sondern für die Scrum Master.

PO (Product Owner) - kein Eigentümer des Geschäfts. Es gibt einen Product Manager - er arbeitet mit den Business Owner'n der entsprechenden Geschäftsbereiche zusammen und verteilt im Wesentlichen die Features an die Product Owner. Der Product Owner arbeitet bereits direkt im Team - zerlegt Features in User Stories (in unserem Fall gemeinsam mit dem Team) und zerlegt nicht immer, aber wir machen in dieser Richtung ständig Fortschritte.

RTE (Release Train Engineer - Zugführer. Scrum Master des Scrum Masters. Führt die SOS-Veranstaltungen seines Zuges durch. Interagiert mit dem Product Manager auf Feature-Ebene. Moderiert PIPE.

Der fünfte Sprint für Schulungen - ja, im Gegensatz zu Scrum ist hier dem Team am Ende des Inkrements ein ganzer Sprint für Schulungen zugewiesen. In der Praxis nutzen wir ihn in der Regel in erster Linie für den Besuch interner Trainings, unter anderem auch zu SAFe, aber nicht nur. Private Kurse und Meetups versuchen wir nach Möglichkeit in diese Zeit zu legen. Außerdem haben wir Entwickler, die ihren Stack im Laufe des 5. Sprints erweitern, damit die Möglichkeit besteht, eine Kompetenz im Team abzudecken (bei Bedarf als Absicherung).

System Demo. Als Ergebnis von PIPE hat jedes Team eine Liste von Zielen für das Inkrement, und jedes dieser Ziele wird vom Business Owner des Zuges auf einer 10-Punkte-Skala bewertet. Das nennt man Business Value. Diese Ziele werden in Haupt- und erweiterte Ziele unterteilt. Hauptziele sind Ziele, bei deren Erreichung das Team keine Risiken sieht. Erweiterte Ziele sind Ziele mit Erreichungsrisiken. Alle Ziele sind verpflichtend, und der Arbeitsumfang wird für alle Ziele geplant. Bei der System Demo nimmt der Business Owner die Arbeitsergebnisse für das Inkrement ab. Nehmen wir an, ein Team hatte 3 Hauptziele mit Bewertungen 10, 6, 8 und 2 erweiterte Ziele mit Bewertungen 10, 3. Stellen wir uns vor, der Business Owner hat entsprechend folgende Bewertungen vergeben: 8, 6, 4, 2, 0. Nun kann man den Prozentsatz der Zielerreichung berechnen: Als 100% wird die ursprüngliche Summe der Punkte für die Hauptziele genommen, in unserem Fall sind das 10+6+8=24. Die erreichten Punkte werden unter Berücksichtigung der erweiterten Ziele gezählt (d.h. 20 von 24 hat das Team erreicht), d.h. als Ergebnis beträgt der Prozentsatz der Zielerreichung des Teams (20*100)/24 = 83,3%. Als normales Ergebnis gilt eine Erreichung von 80% bis 100%.

In allem Übrigen arbeiten wir nach SCRUM. Nun, oder fast in allem :) Was unsere Erfahrung betrifft: Ich kann sagen, dass aus meiner Sicht die Evolution offensichtlich ist. Im Laufe eines Jahres sind die Teams stark gewachsen, sind selbstorganisierend geworden, einige Teams sind zwar zerfallen, aber auch darin ist eine gewisse Evolution erkennbar. Es gibt auch noch Luft nach oben.

Kommentare von Kollegen aus Facebook

«Shenja, hallo! Toll, dass du schreibst, gut gemacht! Ich korrigiere ein wenig bezüglich der Züge - sie bilden sich nicht um das Produkt, sondern um den Wertstrom. Und im Einzelhandel haben wir aus SAFe-Sicht keinen Zug, sondern ein Solution. Nur zur Vereinfachung der Kommunikation und zum besseren Verständnis nennen wir es weiterhin Zug)»

– Konstantin Woronin (Vertreter des Projektbüros der Ingosstrach)

«Nun, und vielleicht bemerkt jemand, dass aus SAFe-Sicht die Bewertung der Ziele im I&A stattfindet; (wo die SD als Teil eingeht, aber nicht direkt mit der Bewertung verbunden ist) und die SD selbst jeden Sprint stattfinden sollten (nach den Team-Demos). Aber davon sind wir noch weit entfernt, deshalb nennen wir bewusst alles so, wie es in deinem Artikel steht)»

– Konstantin Woronin (Vertreter des Projektbüros der Ingosstrach)

«Shenja, mach bitte weiter, sehr nützlich!»

– Alexej Ionow (Zertifizierter SAFe-Trainer)