SAFe Framework: 8 Fallen, die du vermeiden solltest!

SAFe Framework: 8 Stolperfallen

Bei der Einführung des Scaled Agile Framework (SAFe) in Organisationen kann man so einige Fehler machen. Damit die Implementierung bei dir möglichst erfolgreich verläuft, habe ich dir die aus meiner Sicht 8 wichtigsten Stolpersteine in diesem Artikel zusammengefasst.

In der Vergangenheit war ich skeptisch, ob man mit einem solch wuchtigen Framework wie SAFe eigentlich noch agil arbeiten kann. Als ich mich im November 2020 dann zum SAFe Program Consultant (SPC) weitergebildet habe, war ich von den Erkenntnissen positiv überrascht. Keines der vermittelten Konzepte verstößt gegen meine in den letzten Jahren gebildeten agilen Werte oder Prinzipien.

Warum steht SAFe dennoch häufig in der Kritik?

Das liegt vermutlich an

  • den (Miss-)Interpretationen des Frameworks,
  • den Kompromissen, die gemacht werden und
  • an Veränderung, die notwendig ist, aber nicht durchgeführt wird

In meiner bisherigen Projekthistorie sind mir einige Fallen begegnet, die du unbedingt vermeiden solltest.

8 Stolpersteine bei der SAFe Implementierung
8 Stolpersteine bei der SAFe Implementierung

Falle 1: Das SAFe Framework über die Organisation stülpen, ohne bisherige Strukturen zu ändern

Beginnen wir mit einem Klassiker in Veränderungsprojekten.

„Dieses agile Arbeiten klingt ja ganz interessant, können wir machen. Wie jetzt? Wir sollen unsere Abteilungsstruktur auflösen und uns voll und ganz auf die Arbeit im Agile Release Train konzentrieren?“

Kommen dir diese Gedanken bekannt vor?

Ein wichtiges Learning ist: Verändere deine bestehende Struktur und trenne dich von alten Strukturen und Meetings, die durch die neuen Routinen überflüssig geworden sind. Es geht darum, Ballast loszuwerden (merke: einer der Grundgedanken von Lean ist „Eliminate Waste“).

Wenn du jeden Tag ein Daily mit deinem Team durchführst und ihr dort einen Raum für den Austausch habt, wozu braucht ihr dann noch das klassische Statusreporting-Meeting?

Jeder, der den Status, oder besser: euer produziertes Ergebnis sehen will, soll an eurem Iteration-Review teilnehmen. Das spart euch immens viel Arbeit.

Falle 2: Teammitglieder arbeiten in mehreren Solution-Trains gleichzeitig

Ein typisches Bild in Konzernen: Die ohnehin voll ausgelasteten Mitarbeiter haben mehrere Projekte gleichzeitig. Und alle sind gleich wichtig. Alles muss am Besten gestern fertig werden.

Dass Multitasking länger dauert, sollte mittlerweile bekannt sein. Jedes Mal, wenn der Mitarbeiter den Kontext ändert, braucht er einige Minuten, um sich einzufinden. Wenn er alle paar Minuten den Kontext wechselt, verstreichen viele Minuten und Stunden, die dem Switch zum Opfer fallen.

Dieses Phänomen kann man auch bei großen SAFe Implementierungen beobachten. Es kann vorkommen, dass Mitarbeiter in mehreren Release Trains mitarbeiten und nebenbei auch noch ihre Linientätigkeit haben.

Was glaubst du, wie produktiv die Teams in diesem Setting sein können? Was hat das für Auswirkungen auf die Geschwindigkeit der Innovation?

Falle 3: Rollen werden nebenbei gemacht

Abteilungsleiter werden auf einmal zu Product Ownern oder Product Managern gemacht. Soweit erstmal nicht schlimm. Wichtig ist nur, dass man sich genügend Zeit für diese Rolle nimmt.

Die Product Owner oder Product Management Rollen sind Vollzeit-Rollen. Häufig werden sie nebenbei von Abteilungsleitern übernommen, deren Terminkalender auch ohne diese Rolle überquillt.

Was passiert also? Product Owner haben keine Zeit an den Sync-Terminen mit dem Product Management teilzunehmen. Die grobe Richtung des Produkts fehlt.

Der Product Owner nimmt unregelmäßig an den Dailies teil. Kommunikation geht verloren bzw. muss häufig wiederholt werden.

Das sind nur zwei Beispiele für zahlreiche Ineffizienzen…

Besser ist es, Jemanden mit Zeit für diese neuen Rollen zu suchen – auch wenn die Person technisch noch nicht den vollen Überblick hat. Ein starker Scrum Master coacht den Product Owner in enger Abstimmung auf die Rolle und der Abteilungsleiter oder ein Teammitglied mit einem weitreichenden technischen Überblick kann als technischer Sparrings-Partner dienen.

Falle 4: Das SAFe Framework nähert sich immer mehr der bisherigen Linienorganisation an

Man guckt mal kurz nicht hin und… die Organisationsstruktur der Solution sieht irgendwie immer mehr wie die Linienorganisation aus.

3 Monate vergehen, das nächste Program Increment vergeht. Oh… noch mehr Ähnlichkeit?!

Woran kann das liegen?

Besonders, wenn die Solution als Leuchtturmprojekt ausgerufen wird, versuchen Akteure der Organisation ihren Status im neuen Unternehmenskontext zu etablieren.

Bringt das die Solution voran? Eher nicht. Dafür aber die Individualmacht der Systemakteure.

Falle 5: Es gibt keinen Business Owner oder niemand fühlt sich verantwortlich für die Lösung

Das kann doch nicht sein?!

Es muss doch Jemanden geben, der vorgibt, wie die Lösung sein soll und in welche Richtung sie sich entwickeln soll.

Irgendjemand bezahlt doch dieses Vorhaben… oder?

Das ist der Job des Business Owners. Er sollte seine Anforderungen kommunizieren, die Verantwortung für die Lösung tragen und regelmäßig Feedback liefern, damit sich die Systemakteure in die gewünschte Richtung bewegen.

Kein Business Owner vorhanden? Kommt vor. Aber bitte nicht zu lange.

Falle 6: Agile Release Trains orientieren sich nicht am Value Stream, sondern an bestehenden Strukturen bzw. dem, was man kennt

„Ab morgen arbeiten wir mit dem SAFe Framework! – OK, aber wie geht das?“

Der erste Schritt ist getan. Wir haben erkannt, dass unsere Prozesse zu lange dauern und wir flexibler werden müssen.

Wir haben uns für das SAFe Framework entschieden, aber wenige wissen bisher damit umzugehen.

Das ist ok, denn wir lernen ja! Wir müssen das Framework verstehen und es iterativ umsetzen.

Wenn aber wenige bisher wissen, wie man sich nach SAFe organisiert, wie Agile Release Trains geschnitten werden, dann kann das den falschen Grundstein legen.

Wichtig ist daher: Holt euch zu Beginn SAFe Experten ins Boot und schneidet eure Agile Release Trains wertstrom-orientiert. Dazu führt ihr vorher Value-Stream-Workshops durch und schaut, dass ihr in einem Agile Release Train alle Mitarbeiter an Bord habt, die ihr braucht, um die (Teil-)Lösung zu liefern. Stichwort: Cross-funktionale Teams.

Falle 7: Teams werden von allen Seiten mit weiteren agilen Methoden beschossen

In Falle 2 habe ich schon darüber gesprochen, dass man nur in einem Solution-Train arbeiten sollte.

Wenn das bei euch bisher nicht möglich war, dann verschont die Teams bitte davor, sie von allen Seiten mit agilen Methoden zu konfrontieren.

In dieser Solution arbeiten wir nach SAFe, dann gibt es noch eine weitere Solution nach SAFe und auf Abteilungsebene wird zur gleichen Zeit noch Objectives und Key-Results eingeführt.

Was passiert also? Wir befinden uns nur noch in agilen Ritualen und nutzen agile Methoden, wo es nur geht. Und was machen wir in der restlichen Zeit?

Ah ja. Da ist keine restliche Zeit mehr. Es gibt also keine Zeit mehr, die eigentliche Arbeit zu erledigen.

Brauchen wir das alles parallel? Nein, denn es geht um Fokus! Das leitet mich zur letzten Falle.

Falle 8: Das Management priorisiert nicht

Ebenfalls leider ein Klassiker, denn das Thema ist mir oft begegnet.

Für das Management, also z.B. die Business Owner, Solution Management oder Product Management ist alles gleich wichtig.

Wenn alles gleich wichtig ist, dann werden alle Sachen zur gleichen Zeit gemacht und damit dauert alles viel länger (siehe Multitasking).

Eine gute Möglichkeit, um dieses Problem zu lösen ist das folgende Vorgehen. Frage das Management:

„Wenn morgen nur noch die Hälfte der Mitarbeiter zur Verfügung stehen würde, welche Themen wären dann wirklich wichtig?“

Die wirklich wichtigen Themen sind ab jetzt im Fokus, alle anderen liegen zunächst auf Eis. Im Kanban Kontext wird gern von „Stop starting, start finishing“ gesprochen. Darum geht es auch hier.

Fazit

Viele Dinge können schiefgehen – ohne Frage. Sind das Gründe aufzugeben? Sicher nicht. Die Einführung des SAFe Frameworks ist ein Prozess und kein Big Bang.

Auf dem Weg werden wir viel zusammen lernen und die Dinge werden nicht optimal laufen. Darum ist es wichtig, Feedbackschleifen wie Retrospektiven zu nutzen und sich regelmäßig zu hinterfragen, ob man noch auf dem richtigen Weg ist.

Häufig reicht es schon, Dinge zu markieren, die nicht funktionieren und sichtbar zu machen. Hindernisse müssen aus dem Weg geräumt werden. Das gehört zum Prozess!

Ich hoffe, dass ich dir mit meinen Gedanken ein wenig weiterhelfen konnte!

Welche Erfahrungen hast du mit dem SAFe Framework gemacht? Was funktioniert bei euch gut und was nicht so?

Schreib deine Anmerkungen gern in die Kommentare.

Solltest du in deinem Unternehmen Unterstützung von einem SAFe Program Consultant benötigen, dann schreib mir eine kurze Nachricht und ich schaue, ob ich euch unterstützen kann.

P.S.: Ich bin mir bewusst, dass SAFe für „Scaled Agile Framework“ steht und der Titel des Blogartikels „SAFe Framework“ das Wort Framework doppelt vorkommt. Es ist aber etwas, was die Leute bei Google eintippen und zu diesem Keyword möchte ich gefunden werden 😉

Teilen Sie den Beitrag

Share on email
Share on print
Share on facebook
Share on twitter
Share on xing
Share on linkedin

Kommentieren Sie den Beitrag gern!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ebenfalls interessant