
Drei Fallen beim Scaled Agile Framework (SAFE)
Eine Organisation führt SAFe ein, um Agilität, Geschwindigkeit und Anpassungsfähigkeit zu erlangen. Über die Zeit wird aber immer klarer: Sie kann die erhofften Benefits von SAFe nicht auskosten. Woran liegt das?

Es gibt drei Fallen bei der Implementierung von SAFe, in die ich Firmen immer wieder habe tappen sehen. Ich nenne sie die Relabel-Falle, die Linien-Falle und die Agil-auf-Knopfdruck-Falle. Natürlich gibt es ganz viele Hürden bei einer agilen Transformation — und die Einführung von SAFe ist eine solche, bzw. sollte eine sein. Ich habe aber erlebt, dass diese drei die häufigsten Show-Stopper sind für eine wirklich wirkungsvolle Umsetzung des Scaled Agile Frameworks.
DIE RELABEL-FALLE
Die erste Falle nenne ich Relabel-Falle. Sie funktioniert so: Man nimmt das große Schaubild von SAFe, klatscht es auf die bestehende Organisation und labelt nur einfach bestehende Rollen und Strukturen zu SAFe-Rollen und -strukturen um.
So wird irgendjemand vom Business zum PO, meist waren das vorher Projektmanager. Scrum Master werden entweder unterbesetzt (wozu braucht man Scrum Master?) oder ebenfalls von PM-Seite her besetzt. Und Release Train Engineer(RTE) wird ein ehemaliger Projektleiter. Die agilen Teams schließlich sind einfach die Arbeitsgruppen, Abteilungen oder Fachbereiche, die es vorher schon gab.
Und dann arbeiten alle mit kleinen Einschränkungen einfach so weiter wie bisher, die größte Einschränkung besteht dabei im dreimonatlichen Big-Room-Planning, das viele als nervig und sinnlos empfinden, weil die Fachabteilungen ohnehin eigene Pläne verfolgen und die Projektmanager das Jahr mit Gantt-Diagrammen schon durchdekliniert haben. Außerdem gibt es noch sog. Reviews, in denen man auf Powerpoints zeigt, was man gemacht hat, wie in den üblichen Status-Meetings früher auch.
Das ist nicht SAFe. Es ist sogar — sorry für das Wortspiel — ziemlich unSAFe.
Das wichtigste Mittel gegen die Relabel-Falle ist erstens ein Upper Management, das es mit der Veränderung ernst meint und die nötige Macht hinter die SAFe-Implementierung legt, und zweitens, sich Leute ins Haus zu holen, die wissen, wie skalierte agile Arbeit aussieht und sich anfühlt. Es heißt bei Leffingwell, dem SAFe-Begründer, so schön “Train everyone”, aber zwei Tage Training reichen nicht, um gegen 50 oder 100 Jahre Konzernkultur und gewachsene Strukturen anzustinken.
DIE LINIEN-FALLE
Die zweite Falle ist die Linien-Falle. SAFe-Implementierungen passieren meistens im Projekt-Kontext, das heißt, es wird ein großes Projekt aufgesetzt und das will man mit SAFe realisieren. Manche wollen und manche müssen in das Projekt. Die Linie behält Macht, Einfluss und hat eine Agenda außerhalb der Program Increments der Release Trains. Es ist extrem selten, dass ein Release Train völlig unabhängig vom restlichen Unternehmen operieren kann. Er greift zurück auf Funktionen, Dienstleistungen und Strukturen des “restlichen” Unternehmens. Diese Abhängigkeit ist tückisch, denn die Linie hat mindestens zwei Interessen, die dem Train zuwiderlaufen können: Legacy-Strukturen und Machterhalt. Die Linien-Falle ist im Grunde eine häufige Ausprägung der allgemeineren Struktur-Falle. Wenn die Release Trains nicht mit der umgebenden Struktur zusammenpassen oder autonom sind, ist das ein Problem.
Eine Untervariante der Linien-Falle ist die Prozent-Falle. Die Mitglieder des SAFe Release Train sind nicht vollzeit im SAFe-Projekt, sondern haben noch zusätzliche Aufgaben, in anderen Projekten und/oder der Linie. In den meisten Konzernen ist die Arbeit im Projekt die kleine hässliche Schwester der Linien-Karriere, so dass man es im Zweifel der Linie recht macht, schon allein, weil dort die disziplinarischen Vorgesetzten sitzen.
Das Mittel gegen die Linien-Falle ist, möglichst große Unabhängigkeit vom restlichen Unternehmen für die Release Trains zu verwirklichen, Leute unbedingt zu 100% im Projekt zu haben und einen starken Stakeholder aus dem Upper Management zu haben als Fürsprecher für die Bedürfnisse des Trains der Organisation gegenüber.
DIE AGIL-AUF-KNOPFDRUCK-FALLE
Eine dritte Falle ist die Agil-auf-Knopfdruck-Falle, sie funktioniert so: Wir nehmen eine gewisse Anzahl an Leuten, und weil an der Basis des SAFe sogenannte agile Teams stehen, nennen wir diese Gruppen: agile Teams. Wie durch Zauberhand arbeiten diese Teams jetzt nicht mehr auf die Art und Weise, wie sie es bisher gewohnt sind, sondern agil. Mit Scrum, vielleicht mit Kanban, in kurzen, Wert liefernden Iterationen, auf die Nutzer zentriert und als Kernzelle der lernenden Organisation.
Aber in aller Regel haut das so nicht hin. Das ist den Teams nicht vorzuwerfen. Wir können doch auch nicht zehn Leute von der Straße holen, ihnen sagen “Ihr seid jetzt das Badminton-Team der Firma”, wobei sie den Sport noch nie ausgeübt haben, noch nie als Team zusammen gearbeitet haben, und wir geben ihnen noch nicht einmal Schläger! Und dann wundern wir uns, wenn es nicht rockt.
Nur, weil an der Basis von SAFe agile Teams stehen, sind unsere Teams mit der Einführung von SAFe noch nicht agil. Genau genommen: Sie sind noch nicht einmal Teams, wenn sie es nicht zuvor schon waren.
Das Mittel gegen die Agil-auf-Knopfdruck-Falle sind Scrum Master bzw. Agile Team Coaches. Erfahrene Leute, die den Teams beim Forming und Performing helfen und dabei, sich die Mentalität, Motivation und Reflexe anzueignen, die Agilität ausmachen. Das ist ein Prozess, der nicht in wenigen Wochen abgeschlossen ist. Man liest das ja manchmal: “Die Agilität ist jetzt bei uns ausgerollt”. Das sollte misstrauisch machen. Going agile ist es ein Prozess, der niemals aufhört. Denn das ist der Kern von Agilität: Ständiges Lernen! Liefern und Lernen!
Autor
Der vorliegende Artikel wurde von Sacha Storz verfasst. Der Diplom Psychologe ist Agile Coach und Consultant bei der TechDivision GmbH und berät und unterstützt Unternehmen bei deren Agilisierungs- und Transformationsprozessen.