In dieser Artikelreihe diskutieren wir die zwölf Stadien der SAFe-Einführung in Unternehmen. Nachdem wir uns zuletzt mit der Erstellung eines Implementierungsplans beschäftigt haben, wollen wir nun zur Tat schreiten und die Voraussetzungen dafür schaffen, dass unser erster Agile Release Train (ART) losrollen kann.
Die Entwickler von SAFe – Scaled Agile Inc. – benennen die folgenden Schritte, die für die Vorbereitung des ersten ART-Launchs erforderlich sind:
- Den ART definieren
- Launch-Termin und Kadenz des Programmkalenders festlegen
- Die ART-Leader und -Stakeholder schulen
- Die agilen Teams etablieren
- Die Produktmanager und Product Owner trainieren
- Die Scrum Master trainieren
- Die Systemarchitekten schulen
- Die Launch-Readiness beurteilen und erhöhen
- Den Program Backlog vorbereiten
Gehen wir auf diese Schritte mal näher ein.
Den ART definieren
Im dritten Teil dieser Reihe haben wir bereits über das Identifizieren von Wertströmen und ARTs gesprochen, während wir in Teil 4 Tipps für die Erstellung des Implementierungsplans geben. In diesem Schritt haben wir den ART soweit definiert, dass wir wissen, dass es tatsächlich ein ART ist. Da unsere Gruppe von SAFe Agile Practicioners (SPCs) Leader aus unterschiedlichen Disziplinen innerhalb der Organisation umfasst, brauchen wir nun Leute mit stärker fokussierten Erfahrungen, um die Details des ARTs klar zu definieren.
Das vorgeschlagene Canvas von Scaled Agile sieht so aus:
Ein Canvas zur Beschreibung des Agile Release Trains, (c) Scaled Agile Inc.
Eine der hilfreichsten Funktionen dieser Vorlage besteht darin, dass sie uns dabei unterstützt, herauszufinden, wer im ART was tut. Damit das System gut funktioniert, müssen alle im Team ihre Verantwortlichkeiten verstehen. Im Ergebnis brauchen alle Teile der Lösung einen "Owner".
Launch-Termin und Kadenz
Manche Leute mögen es nicht, mit Deadlines zu arbeiten; andere Teams finden das Setzen von Deadlines wiederum motivierend, um Arbeit zu schaffen. Wenn es uns gelingt, mit all den ART-Stakeholdern einen Launch-Termin festzulegen, kann das durchaus zur Entstehung einer übergreifenden Motivation beitragen.
Darüber hinaus ist die Etablierung einer Kadenz für unsere Programminkremente (PIs) nötig. Wir bekommen ein Gespür für die Länge, wenn wir uns mit den Stakeholdern in unserem ART unterhalten. In der Regel werden für ein PI zwischen acht und zwölf Wochen veranschlagt. Auf der SAFe-Website wird von zehnwöchigen PIs ausgegangen, die je vier reguläre Iterationen und eine Innovations- und Planungsiteration beinhalten. Es gibt jedoch keine feste Regel für die PI-Länge, aber wenn wir unsere Dauer gewählt haben, sollten wir sie beibehalten, damit das Team seine Kadenz etablieren kann.
Die fixe PI-Länge erlaubt es allen Beteiligten, genau zu sehen, was in der nahen und längerfristigen Zukunft ansteht. Im Hinblick auf die Kadenz und die Events gibt es etliche Parallelen zu Scrum. In SAFe hat ein typisches PI die folgenden Events:
- PI-Planning (analog zur Sprintplanung)
- System-Demos (analog zum Sprint-Review)
- ART-Synch oder individuelle Scrum of Scrums und PO-Synch (analog zum Standup)
- Inspect & Adapt-Workshops (analog zur Retrospektive)
Diese wichtigen Termine weisen unverkennbare Ähnlichkeiten zu den Plannings, Reviews, Standups und Retros im Scrum-Prozess auf. Es ist empfehlenswert, diese Termine im Verlauf der Iteration frühzeitig auf dem Schirm zu haben und einzuplanen. Dann können die PI-Mitglieder auch ihre Planungen für die notwendigen physischen Meetings rechtzeitig in Angriff nehmen.
ART-Leader und -Stakeholder schulen
Im Idealfall haben die SPCs bereits all die individuellen ART-Leader und -Stakeholder geschult. Aber das ist sehr unwahrscheinlich, denn die Leute sind nun mal beschäftigt. Falls die Leader des spezifischen ARTs noch kein Training erhalten haben, wäre jetzt ein guter Zeitpunkt für solche Trainings.
Kurz nach den Schulungen wenden wir uns normalerweise direkt der Implementierung zu, da das Wissen und die Prinzipien frisch verankert sind.
Die agilen Teams etablieren
SAFe ist in hohem Maße abhängig von den Leuten und Teams, die im Rahmen des Frameworks zusammenarbeiten. Wir können das beste Framework mit wertgetriebenen ARTs aufsetzen, aber wenn Teams komplett isoliert arbeiten, wird der ART scheitern.
Die initiale Etablierung der Teams im ART kann in zwei Tagen abgeschlossen sein. Ein Weg besteht darin, dass wir die Mitglieder des ARTs ermächtigen, selbst agile Teams zu formen. Der andere Weg ist, dass das Management der Organisation die Teams basierend auf den unterschiedlichen Talenten im ART zusammensetzt.
Die Mitglieder der agilen Teams werden ein gutes Verständnis davon haben, wie sie gut zusammenarbeiten. Letztlich füllen sie ihre Rollen im Unternehmen wahrscheinlich schon einige Zeit aus. Das Management sollte zusätzlich dabei helfen, die Teams entsprechend der individuellen, organisatorischen und produktspezifischen Strategien des Unternehmens zu führen.
Bevor schließlich ein PI-Planning stattfinden kann, muss jedes ART-Mitglied einem agilen Team angehören. Es müssen außerdem Product Owner und Scrum Master festgelegt werden. Hier ist ein Beispiel für eine Teamliste von Scaled Agile:
Eine Liste für den Aufbau der agilen Teams, (c) Scaled Agile Inc.
Wenn uns mit den Teamzusammensetzungen beschäftigen, werden wir wahrscheinlich ein paar interessante Entdeckungen machen. Womöglich stellen wir fest, dass eine Person in mehr als einem Teams arbeitet, was im agilen Kontext natürlich alles andere als ideal ist. Vielleicht bemerken wir auch, dass Teammitglieder über viele geographische Standorte hinweg verteilt sind.
Gewiss wären Teams an ein und demselben Standort ideal, aber auch eine räumliche Verteilung über Zeitzonen hinweg ist akzeptabel. Wenn das Team erstmal etabliert ist, richten sich die Mitglieder erfahrungsgemäß schnell auf Termine wie Standups und Retrospektiven ein.
Schulung der Produktmanager, POs, Scrum Master und Systemarchitekten
Leute wie die Produktmanager, POs und Produkt-Marketing-Experten, die nah am Produkt arbeiten, müssen in SAFe trainiert werden. Diese Rollen sind in Software-Unternehmen besonders kritisch, da diese Personen letztlich die Richtung des Produkts bestimmen. Diese Personen benötigen SAFe-Schulungen, um die Zusammenarbeit weiterzuentwickeln, um die neuen Prozesse und Arbeitsmethoden kennenzulernen und um ihre Verantwortlichkeiten so gut wie möglich auszufüllen.
Das Training der Scrum Master ist wiederum ein anderes Feld. SAFe setzt voll auf die "dienende Führung" der Scrum Master. Sie verbringen viel Zeit damit, ihre Teammitglieder zu schulen und die Prozesse des Teams effizienter zu machen. Was gute Scrum Master wert sind, wird auch im PI-Planning deutlich. In diesen Meetings helfen sie, die wertgetriebene Auslieferung zu fördern und zu verbessern. Dafür brauchen sie Training.
Schließlich müssen auch die Systemarchitekten im Team geschult werden. Sie treiben die technologische und architektonische Entwicklung an und brauchen Know-how, wie sie bestmöglich zusammenarbeiten und den Stakeholdern helfen, die besten Entscheidungen für die Lösungen des Unternehmens zu treffen.
Launch-Readiness einschätzen
Das Training ist lediglich ein Teil auf dem Weg zum ART-Launch. Es gibt kein perfektes "Bereit"-Stadium, aber einige "Readiness"-Knackpunkte sind gleichwohl erforderlich. Die beiden folgenden Übersichten von Scaled Agile können als Checkliste dienen, um einzuschätzen, wo wir stehen und ob wir soweit sind, den ART zum Leben zu erwecken:
Scaled Agile zufolge sind die Aspekte auf dem ersten Bild essenziell für einen erfolgreichen ART-Launch. Die Bereiche und Fragen auf dem zweiten Bild können wir als "Nice to have"-Features bewerten.
Program Backlog vorbereiten
Der Program Backlog wird der zentrale Ort für all unsere Programminkremente sein. Hier bilden wir eine Liste unserer Features, nicht-funktioneller Anforderungen und architektonischer Arbeiten ab, die die zukünftigen Stadien unserer Lösung definieren.
Oft bringen SPCs und Mitglieder des Lean-Agile Center of Excellence (LACE) Stakeholder aus unterschiedlichen ARTs zusammen, um den Backlog zu determinieren. Das wird nicht in einem einzelnen Meeting oder an einem Nachmittag gelingen, sondern es kann ein längerer Prozess sein, der nicht zuletzt davon abhängt, wie unterschiedlich die Meinungen sind.
Erfahrungsgemäß ist es bei der Arbeit mit SAFe-Teams nicht empfehlenswert, in jedem PI ganz tief in die Details einzusteigen. Oft ist eine Feature-Liste mit gradlinigen Akzeptanzkriterien ausreichend, um zu starten. Letztlich sind es die individuellen agilen Teams, die am besten wissen, wie diese Features implementiert werden.
Im demnächst folgenden sechsten Teil der Serie wollen wir dann sehen, wie wir unseren Agile Release Train tatsächlich aus dem Bahnhof bekommen.
SAFe mit Atlassian: Jira Align jetzt kennenlernen!
Wollen Sie mehr über die Software-gestützte Umsetzung von SAFe in großen Unternehmen wissen? Eine Lösung dafür ist Jira Align von Atlassian. Gerne diskutieren mit Ihnen über Ihre Anforderungen an ein unternehmensweites agiles Produktentwicklungs- und Produktmanagement und demonstrieren Ihnen die Möglichkeiten der Software in einer persönlichen Session. Melden Sie sich bei uns!
Weiterführende Infos
Agile-Skalierung mit Jira Align: Abhängigkeiten überwinden, Teams auf eine Linie bringen, kontinuierlich Wert ausliefern
Jira Align: Werkzeuge für ein systematisches agiles Programm-Management
Best Practice RTE: Wie Skalierung mit SAFe gelingt
Agile-Skalierung und SAFe im Konzern – Ein Interview mit Scaled-Agile-Coach Burkhard Schmidt
