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