Folge 068 Wie SAFe skalierst Du

Wie SAFe skalierst Du?

Heute geht es darum wie das Skalierungs-Modell SAFe funktioniert.
Es ist ein Hörerwunsch vom lieben Carsten und wir nehmen uns
diesem daher schon einmal gern an.


Das Thema ist zu groß für den Podcast und bräuchte eigentlich
einen eigenen Podcast. Wir geben Dir trotzdem einen kleinen und
schnellen Überblick in zwei Folgen darüber wie SAFe funktioniert
und was es damit auf sich hat.


In der kleinen Scrum Schule (die nun Heldentreff heißt) kam das
Thema auch schon mehrfach auf. Es ist also Zeit SAFe mal für Dich
unter die Lupe zu nehmen.


Diese Folge auf YouTube: https://youtu.be/bky1tTEHM_g
SAFe steht für

SAFe steht für Scaled Agile
Framework und ist aktuell in
der Version 5.1 unter www.scaledagile.com zu finden. Als
Grundlage für die Podcastfolge diente unser Stand zur Version
5.0. Es handelt sich dabei um eine eingetragene Marke der Scaled
Agile, Inc.


Ich persönlich finde den Namen marketingtechnisch sehr clever
gewählt. Denn wer möchte schon LeSS, wenn er SAFe haben kann?


Da Fachwissen und Agile Frameworks eher Henrys Bereich sind gibts
heute auch mehr Input von ihm zum Thema.
Was ist SAFe?

Das Wort SAFe bedeutet ja übersetzt Sicherheit und damit vom
Marketing her clever gewählt. Es handelt sich um einen skalierten
Agile Framework. Das bedeutet, es ist ein Framework, wie auch
Scrum und beschäftigt sich primär mit anderen Effekten. Skalierte
Frameworks brauchst Du erst, wenn Du mehrere agile Teams hast,
die miteinander zusammenarbeiten wollen. Erst dann nimmt die
Kommunikationskomplexität drastisch zu und ein Framework kann
helfen. Bis 2 Teams sollten sie es alleine hinbekommen und ab 4
wirds interessant. Hier hast Du dann 2 Optionen: Deine Firma
entwickelt ein eigenes Skalierungsmodell oder Du nimmst ein
fertiges vom Markt. Fertige Skalierungsframesworks sind zum
Beispiel SAFe, LeSS, NEXUS, DAD oder Spotify. Alle haben ihre
Vor- und Nachteile. SAFe ist nach dem aktuellen Scrum Master
Trends Report das verbeitetste. Vorher war es NEXUS.


Abgesehen vom guten Marketing ist SAFe auch, Henrys Meinung nach,
ein gutes Framework für skaliertes Arbeiten. Das ist gut und auch
schlecht. Gut, weil wir einen mächtigen Hebel für Agilität und
besseres Arbeiten in die Organisation bekommen. Schlecht, weil es
oft von Laien implementiert wird. Meist nur weil es gerade in ist
und man die Hierarchie behalten kann.
Sollte ich skalieren?

Kurze Antwort: Nein. Lass es!


Warum? Viele Organisationen skalieren viel zu früh. Stell Dir
diese Frage nicht zu Beginn. Schau Dir erst einmal Team aus und
mach dieses zu einem Team und richtig Agil. Wenn es dann
anwächst, dann mach ab 14 Mitglieder eine Zellteilung. Diese
nehmen dann die gute agile Implementierung mit und tragen diese
weiter. Beide Teams werden auch miteinander gut klarkommen ohne
Framework. Ab 4 Teams kannst Du darüber nachdenken ob ihr eine
firmenspezifische Lösung schafft oder ein Framework aus dem
Methodenkoffer nehmt. Achtung: SAFe beginnt erst ab 50 Personen.
Hast Du keine 50 Personen bereits an Board, machst Du auch kein
SAFe. So einfach ist das.


Wenn Du gleich skalierst, dann skalierst Du viele merkwürdige
Dinge, weil das Agile Mindset noch nicht sitzt. Durch die
Skalierung wird es aber multipliziert und verankert. Es ist dann
oft schwer das später wieder aufzuräumen und vor allem unnötig.
Warum Skalierungs Frameworks?

Frameworks wie Scrum, Kanban und XP beschäftigen sich primär mit
dem einen Team. Diese Frameworks brauchst Du sicherlich auch in
einem skalierten Umfeld weiterhin für die Teams. Nun müssen diese
Teams, wenn sie am selben Produkt arbeiten, sicherlich auch
irgendwie zusammenarbeiten. Wenn es mehr als zwei, eher in
Richtung 4 Teams sind, dann könnte das ein guter Moment für
Skalierung sein, damit die Zusammenarbeit an demselben Produkt
auch weiterhin gelingt.


Der naheliegendste skalierte Framework wäre erst einmal ein Scrum
of Scrums. Also wir nutzen auch Scrum zur Abstimmung der Teams
auf einer übergeordneten Ebene. Dabei betrachten wir jedes Team
wie ein Teammitglied im Scrum of Scrum. Nun fängt es an komplex
zu werden. Wann sind zum Beispiel die Dailies und wer hat 2
Dailies? Also das mit seinem Team und das übergeordnete. Bilden
sie Scrum Master dann auch ein Team? Wie laufen Retrospektiven
ab? Haben alle denselben Takt? Du merkst, es wird komplexer in
der Zusammenarbeit. Und hier liefern Frameworks gute Antworten.
SAFe baut gute Metaphern auf

Unser Teams bauen zusammen an einem Zug. Einen sogenannten
Release Train. Das ist das Produkt. Dieser Zug kommt immer
pünktlich am Bahnhof an und fährt auch immer pünktlich los. Wer
nicht rechtzeitig an Bord ist darf auf den nächsten Zug warten.
Hierin ist ein starker Takt und ein starkes Commitment zum
Release versteckt. Denn anders als im klassischen
Projektmanagement wird der Releasetermin nicht verschoben. Der
Zug fährt ab! Bist Du zu langsam nimm halt den nächsten.


Wenn der Zug im Bahnhof ist werden die einzelnen Wagons
angekoppelt. Jeder Wagon ist eine Funktion. Ob jedes Team nun
einen Wagon hat oder mehrere Teams gleichzeitig an einem Wagon
arbeiten ist Entscheidung der Organisation.
SAFe bedient sich den Prinzipien aus anderen Frameworks

Ähnlich wie wir es an der Znip Academy auch machen mixt SAFe die
Prinzipien und Praktiken der unterschiedlichen Agilen Richtungen
sinnvoll miteinander. Bei uns kannst Du das bestens im
Flexibilitätsseminar erfahren. Dort mixen wir KanBan und Scrum
miteinander. Das macht SAFe auch. Im Release Train finden wir
viel aus der Scrum Welt. Auf der Portfolio Ebene mehr Lean und
KanBan.
Der Takt

An Takten habe ich bereits viele verschiedene Implementierungen
gesehen. Von 6 bis 12 Wochen war alles dabei. Am häufigsten
scheint quartalsweise zu sein, was denke ich mal auch gut im Kopf
bleibt. Die Teams untereinander können andere Takte haben und
sich entsprechend miteinander auf Synchronisationspunkte einigen.
Beispielsweise alle zwei Wochen. Der Takt des Release Trains
(Bahnhofsaufenthalt) ist so wichtig, da im Safe dafür alle zu
einem sogenannten PI-Planning (auch PIP genannt) zusammen kommen.
PI bedeutet Program Increment. Im Pdocast habe ich leider Product
Inctement gesagt. Dies beinhaltet sowohl das Review, das Planning
als auch die Retrospektive und das Netzwerken zum Release Train.
Dafür ist ein physisches Zweitagesevent vorgesehen. Du merkst
schon eine Organisation, die größer als 50 Menschen ist zwei Tage
physisch zusammen zu bringen, das ist schon ein Akt. Deshalb das
PI-Planning sorgfältig planen und durchführen.


Wir sprechen immer davon wie wichtig es ist alles 6 Mal zu
wiederholen damit es sich etabliert. Auch hier könntest Du mit
Deiner Implementierung also schneller vorankommen, wenn die
Zyklen kürzer sind.
PIP

Beim Program Increment Planning werden nun die Wagons an den Zug
angehängt. Diese werden dabei natürlich überprüft ob sie zu dem
Zug passen und dieser damit auch starten kann. Dann wird geschaut
wo die Organisation überhaupt hin will und entsprechend anhand
des Backlogs und der Ziele geplant. Das bedeutet auch, dass die
Product Owner richtig gut vorbereitet sein müssen. Danach folgt
die Retrospektive und das Netzwerken.


Unter PI Planning – Scaled Agile Framework gibt es einen guten
Vorschlag wie das PI-Planning ablaufen kann.


Du merkst schon, es wird komplex. SAFe schreibt daher zwingend
einen gut ausgebildeten SPC (SAFe Program Consultant) für die
Implementierung vor. Dazu rate ich auch. Auch die anderen Rollen
sollten bereits vorher gut ausgebildet sein.
Release Train Engineer (RTE)

Der Release Train Engineer steht dem SPC zur Seite und ist eine
Art übergeordneter Scrum Master. Er hat sich darum methodisch zu
kümmern, dass der gesamte Release Train und sicher auch die
PI-Planning gut laufen. Ja an der Stelle könnte man wirklich
erfahrene Scrum Master, die etwas mehr auf der Meta Ebene
arbeiten wollen, auf diese Stelle befördern.


Der RTE wird häufig als eine Art Lockführer dargestellt. Es würde
mehr passen ihn als Schaffner zu sehen.
Weitere Rollen

Es gibt noch den System Architect und den Product Manager. Der
Architekt kümmert um die übergeordnete Architektur, dass alles
zusammenpasst. Also der Zug auf die Schienen passt und die
Verbindungsstücke der Wagons in Ordnung sind. Der Product Manager
kümmert sich um die Funktionsplanung des Produktres und die
jeweiligen Releases. Dieser hat einen richtig krassen Job, denn
er darf die Product Owner in den Teams koordinieren und mit ihnen
die PI-Plannings vorbereiten. Dieser darf auch den Train nach
oben repräsentieren, Marketing machen und sich auf Portfolioebene
entsprechend zusätzlich abstimmen. Dabei darf er auch den Kunden
nicht vergessen. Das ist taff! Der Product Manager arbeitet auf
einer höheren Ebene mit Epics, Enabler und Features. Also nicht
mehr auf Task und Story Ebene. Eben eine Ebene höher und etwas
globaler. Dafür hat er ein eigenes Backlog für diesen Release
Train.
Netzwerken

Die Organisation, die an demselben Produkt arbeiten soll ist
recht groß. Plane viel Netzwerken ein, damit sich die Mitglieder
der Organisation gut kennen und informell miteinander in Kontakt
kommen um Dinge zu klären.
Die Rollen Hierarchie

Ich weiß es ist verlockend einfach herzugehen und die alte
Organisation (vor SAFe) zu betrachten in ihrer Hierarchie und
dann im SAFe ähnliche Hierarchien zu vergeben. Also aus dem
Abteilungsleiter wird der Product Manager und aus dem
Unterabteilungsleiter vielleicht der Release Train Engineer oder
ähnliches. Es gibt genug Rollen und ich sehe das viel zu oft,
dass genau dies gemacht wird. Ich würde die Rollen nach den
jeweiligen Stärken der Mitglieder bestimmen und besetzen. Es kann
sehr gut sein, dass sich eine Führungskraft extrem gut als RTE
eignet. Als Product Manager würde ich aber einen Projektleiter
einsetzen und nicht unbedingt einen Abteilungsleiter. Hier also
aufpassen. Die Herarchie sollte neu gewürfelt werden oder alle
Chefs auf die Portfolio Ebene.
Du machst kein SAFe wenn

Du machst kein SAFe wenn


die Teams nicht am selben Produkt arbeiten

Du weniger als 50 Menschen diesem Produkt zugehörig hast

Niemand in Agilität ausgebildet ist

kein Team vorher agil zusammengearbeitet hat

es kein gemeinsames Ziel gibt

die Organisation den Takt nicht halten will

SAFe selbst skalieren

Du hast mehr als 125 Produktbeteiligte? Dann kann man auch SAFe
weiter skalieren bis hin zu Full SAFe. Bisher haben wir nur
Esential SAFe betrachtet.


Eine mögliche Skalierung könnte sein mehrere Release Trains zu
einem Solution Train zusammen zu fassen. Natürlich mit den 3
Rollen nochmals darüber. Also ein Solution Architect, ein
Solution Train Engineer (STE) und einem Solution Manager. Der
Solution Train besteht dann aus mehreren Release Trains.
Portfolio Ebene

Die Portfolio Ebene ist die strategische Ebene mit den Menschen,
die das Sagen in der Firma haben. Diese arbeiten nach Lean
Prinzipien und denken die Firma ein paar Jahre weiter und stellen
strategische Weichen. Beispielsweise kümmern sie sich darum wie
viele Ressourcen den Trains zur Verfügung stehen.


 


Get shit done,


Janina & Henry


Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen
weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du
magst verlinke @znip_academy_agile und wir teilen deinen Like mit
unseren Hörern.


Du möchtest dich von uns in der Tiefe in eurem
Veränderungsprozess begleiten lassen, eure größten
Komplexitätsnester auflösen und die besten Teamtipps bekommen?
Dann bewirb dich gerne für unser True Leader Coaching:
https://znip.academy/produkt/scrum-master-coaching – Durch deine
Bewerbung hast du die Chance auf einen der nächsten freien
Plätze.


In der Podcastfolge erwähnte Folgen zur Vertiefung:


Scrum Master Trends Report

Agilität was bedeutet das?

Mindset

Scrum

Kanban

Team

Retrospektive

Backlog

Ziele

Product Owner



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post Folge 068 Wie SAFe skalierst Du appeared first on
Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan,
Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy.