Seit drei Jahren führe ich SAFe-Artefakte in einer großen öffentlichen Organisation ein. Ich bin zertifizierter SAFe SPC und schätze SAFe als den einzigen praxistauglichen Leitfaden auf dem Markt, der zumindest in Teilen eine konkrete Blaupause für die Transformation großer Organisationen liefert. Aber das heißt noch lange nicht, dass das Framework in meiner täglichen Praxis funktioniert – und vermutlich tut es das in Ihrer auch nicht. Kritik an SAFe gibt es genug. Hier ist mein eigener Blick darauf.

Die Welt ist nicht nur digital

Diese triviale Feststellung ist offensichtlich für Unternehmen, die physische Güter oder Dienstleistungen anbieten, welche die Mitarbeit von echten Menschen erfordern. Das „Produkt“, das hier geschaffen oder verbessert werden soll, kann zum Beispiel ein Beratungsprozess sein, der am Telefon oder am POS stattfindet, die Abläufe für das medizinische Personal im Krankenhaus oder der Verkaufsprozess im Baumarkt. Diese Prozesse sollen gestaltet, entwickelt und in Betrieb genommen, der Erfolg gemessen und der Prozess kontinuierlich verbessert werden.

SAFe bietet im Entwicklungsprozess aber nur den Mechanismus des Agile Release Train (ART) an, der für eine kontinuierliche Softwarebereitstellung konzipiert ist. Die verantwortlichen Rollen haben deshalb auch Bezeichnungen wie „Release Train Engineer“ (RTE), die in der Realität vieler Unternehmen einfach nicht passend sind. Wozu brauche ich einen RTE, wenn mein Produkt ein Gesprächsleitfaden für ein Kundengespräch ist?

Ebenfalls in diesem Kontext völlig unpassend ist das ausführliche und detailgenaue Mandat des „Program Increment“ (PI) Plannings des ART – nicht nur wegen seiner technischen Ausrichtung, sondern auch wegen der Prämisse fester Release-Zyklen. Teams, deren Aufgabe es ist, Problemlösungen für die physische Welt zu entwickeln, arbeiten faktisch in einem kontinuierlichen Fluss und sollten sich eher an einer Kanban-Logik orientieren. Eine Taktung in festen Zeitabschnitten kann für die übergeordnete Planung und Zielsetzung sinnvoll sein, um sie an den Finanzzyklen des Unternehmens auszurichten, wird ansonsten aber als künstlich aufgesetzt und störend empfunden.

Wertschöpfung in der physischen Welt findet immer noch genauso statt wie im Digitalen. Ein vollständiges Rahmenwerk muss Möglichkeiten schaffen, diese hybride Realität in eine Transformation einzubeziehen.

Entkopplung der Produktverantwortung

SAFe ist darauf ausgelegt, die Produktverantwortung auf der Agile-Release-Train- oder Solution-Train-Ebene anzusiedeln (beide sind ein fester Teil der vorgeschlagenen Managementstruktur). Das hat vermutlich den Hintergrund, dass SAFe am Beispiel eines Unternehmens entwickelt wurde, das wenige, aber sehr umfangreiche Softwareprodukte herstellt, bei denen viele Teams an einer einzigen, gemeinsamen Codebasis arbeiten. Wenn mehr als 100 Entwickler benötigt werden, um ein einziges, singuläres Produkt zu bauen, soll es sinnvoll sein, an übergeordneter Stelle eine verantwortliche Rolle zu installieren, die die zugeordneten Teams steuert. So die Hypothese.

Ich will nicht sagen, dass es keine Unternehmen gibt, für die dieser Ansatz funktioniert, aber ich bezweifle es für die meisten. In der Realität bestehen die meisten Produkte aus sinnvoll trennbaren Bestandteilen, für die es jeweils eine (teil-)produktverantwortliche Person geben kann, die eigenverantwortlich operiert. Oder aber das Unternehmen hat ohnehin eine Vielzahl eigenständiger Produkte mit fester Verantwortungszuteilung.

Natürlich müssen sich in jedem Unternehmen alle Akteure abstimmen, eine übergreifende Produktvision entwickeln und diese gemeinsam tragen. Aber graduelle Abstufungen in der Produktverantwortung sind in SAFe schlicht nicht vorgesehen. Auch Ansätze, wie eine solche gemeinsame Vision in einem Umfeld mit vielen dezentralen Verantwortungsträgern entstehen kann, fehlen. SAFe fehlt die Flexibilität, Teams dort Autonomie und Verantwortung zu übertragen, wo sie gebraucht werden.

Wird das System starr nach Lehrbuch angewendet, wertet dies die Teamebene ab und degradiert Product Owner zu reinen Backlog-Verwaltern und Ticket-Schreibern. In der Folge leidet die Produktivität, da die Potenziale der Teams ungenutzt bleiben und das System verliert massiv an Akzeptanz, gerade bei den kompetentesten und engagiertesten Product Ownern und Entwicklern.

Das „Alles-oder-nichts“-Reorganisations-Dilemma

Auch das folgende grundsätzliche Argument sollte eigentlich selbstverständlich sein. Die Entscheidung zur Reorganisation eines Unternehmens hat immer einen Hintergrund. Dieser kann beispielsweise eine organisatorische Sackgasse sein, eine plötzliche Veränderung der Marktsituation, mit der die Organisation konfrontiert ist, oder schlicht der Bedarf und Wille zu einer fortlaufenden Verbesserung, um es erst gar nicht so weit kommen zu lassen. Im ersten Fall kann ein radikaler Umbruch der Organisation notwendig sein, im letzteren wohl eher nicht. Die möglichen Strategien der Organisationsentwicklung reichen dementsprechend von einem „vorsichtigen Umbau“ bis hin zum „radikalen Schnitt“.

Und selbst wenn der Wille vorhanden ist, ist eine vollständige Reorganisation nicht immer machbar. In regulierten Umfeldern oder Unternehmen des öffentlichen Sektors ist die primäre Organisationsstruktur beispielsweise oft gesetzlich vorgegeben. Bestehende Abteilungen können nicht aufgelöst werden, ohne den rechtlichen Rahmen der Institution selbst zu ändern.

Unabhängig davon, welcher Organisationstheorie man anhängt: Sicher ist, dass nicht alle Unternehmen gleich sind und ein starres Konzept für alle keinen Sinn ergibt. SAFe fordert jedoch genau das – eine fundamentale Neuausrichtung der Struktur um den Wertstrom herum. Eine Übergangsarchitektur oder Alternativkonzepte, wie der Aufbau einer Sekundärorganisation bei Erhalt der primären Disziplinarstruktur, sucht man im Framework vergeblich. Damit sollte die buchstabengetreue Anwendung von SAFe für viele Unternehmen von vornherein ein No-Go sein.

Fehlende Nutzerzentrierung und Service Design

Die SAFe-Autoren Dean Leffingwell und Drew Jemilo haben ihren beruflichen Hintergrund im Ingenieurwesen und in der klassischen Softwareentwicklung. Es verwundert daher nicht, dass bestimmte Transformationsaspekte im Vordergrund stehen, während andere zu kurz kommen (um es vorsichtig auszudrücken). Am deutlichsten wird dies für mich beim Thema Design – zugegebenermaßen auch aufgrund meines eigenen beruflichen Hintergrunds.

Zwar werden „Customer Centricity“ und „Design Thinking“ in SAFe als Konzepte erwähnt, bleiben aber bei genauerem Hinsehen unvollständig, missverständlich oder schlicht falsch interpretiert. In SAFe 5 wurde Design Thinking im Kern noch als reine Methode verstanden, um „das Risiko zu minimieren, das Falsche in perfekter Geschwindigkeit zu bauen“, was dem üblichen Verständnis von Design Thinking objektiv einfach nicht gerecht wird. In Version 6 wurde dies zwar oberflächlich korrigiert, indem im Bereich „Agile Product Delivery“ die Werkzeuge Personas, Empathy Maps, Customer Journey Maps und Story Mapping integriert wurden. Doch auch das greift zu kurz und wäre im Kern ohnehin besser mit dem Begriff Service Design beschrieben (wobei die genannten Methoden nur einen kleinen Teil des Service Design abdecken).

Was in SAFe fehlt, ist eine systematische Integration kreativer Arbeit und moderner Anforderungsanalyse auf allen Ebenen des organisatorischen Gefüges, um etwa die erwähnte gemeinsame Produktvision kollaborativ zu entwickeln. Es gibt dann auch weder Ansätze für eine echte siloübergreifende, multidisziplinäre Zusammenarbeit noch einen konkreten Blueprint zur systematischen Einbindung von Endanwendern in den Entwicklungsprozess, wie er auch in der ISO 9241 – 210 definiert ist. Die vorgeschlagenen Methoden wirken etwas hilflos an das bestehende System angedockt, beispielsweise als bloße „Vorbereitung für die PI-Planning-Events“. Das Wort Nutzerzentrierung ist in SAFe am Ende nicht viel mehr als ein Feigenblatt.

Wertdefinition jenseits von operativem Output

Folgerichtig zu dem erwähnten Schwerpunkt auf der technischen Umsetzung hat SAFe auch einen blinden Fleck bei der Definition dessen, was im eigenen Framework (richtigerweise) den Kern der Organisation ausmacht: der Wertschöpfung bzw. dem Wertstrom. Jede Organisation mag ihre eigene Vorstellung davon haben, was einen „Wert“ darstellt, der erzeugt werden soll. Die Sichtweise wird von Unternehmen zu Unternehmen naturgemäß weit auseinandergehen. SAFe bietet hier jedoch nur eine sehr operative Definition an.

In SAFe leitet sich der Begriff „Wert“ (Value) maßgeblich von einem operativen Durchsatz im Stile der klassischen Fertigung ab – vergleichbar mit dem Schneiden, Stanzen, Polieren und Versenden physischer Güter. Das Framework unterscheidet dabei zwischen dem operativen Wertstrom (dem tatsächlichen Erbringen von Dienstleistungen oder Produzieren von Produkten) und dem Entwicklungswertstrom (dem Verbessern der operativen Wertströme). Der Gedanke dahinter scheint zu sein: Wenn die Produktion effizient organisiert ist, entsteht der „Wert“ von allein. Aber welcher Wert entsteht da eigentlich? Ist Wert immer in Geld umzusetzen?

Das Framework bietet keine Modelle, um nicht-monetäre, übergeordnete Effekte wie langfristige Kundenzufriedenheit, gesellschaftlichen Nutzen (Public Value) oder Verbesserungen der Lebensqualität für Menschen in den täglichen Betrieb zu übersetzen. Wie organisiert man ein Unternehmen, das sich zum Ziel setzt, Menschen glücklich machen zu wollen? Oder etwas naheliegender, wie kann ein wichtiger Wert wie “Vertrauen in staatliche Organisationen schaffen” als Wert für ein öffentliches Unternehmen verankert werden?

Wenn eine Organisation sich „um den Wert herum“ strukturieren soll („organize around value“), dann muss das Rahmenwerk auch Werkzeuge anbieten, um diese strategischen, nicht-monetären Werte sauber zu definieren und operativ zu verankern.

Das agile Paradoxon

SAFe ist extrem umfangreich und komplex. Es führt eine Reihe spezialisierter, künstlicher Rollen ein, sieht jedoch keinerlei Anpassungen am eigenen Rahmenwerk vor und dementsprechend auch keine organisatorischen Formate, um solche Anpassungen überhaupt zu planen und durchzuführen. SAFe ist schwer zu erklären, erzeugt eine erhebliche kognitive Belastung und führt auch deshalb zu Widerständen bei genau denjenigen, die es bei der Arbeit eigentlich unterstützen sollte.

Warum die Autoren, die ja nach eigener Aussage Experten für „agiles Arbeiten“ sind, einen derart starren Ansatz gewählt haben, bleibt ein Rätsel. Vielleicht sind Leffingwell und Jemilo am Ende dann doch eher old school Manager als Entwickler. Oder aber – meine persönliche Verschwörungstheorie: Das starre System ist schlicht eine Folge des Geschäftsmodells von Scaled Agile, Inc. mit seinen standardisierten, globalen und zertifizierbaren Schulungspfaden. Es ist zweifellos einfacher, teure Kurse zu verkaufen, wenn das geschriebene Buch die einzige Quelle der Wahrheit ist. Die beste Lösung für Ihr Unternehmen ist es sehr wahrscheinlich nicht.

Wo sind die Alternativen?

Organisationale Agilität erfordert das Gegenteil von SAFe: ein minimalistisches Framework, das Unternehmen die Werkzeuge an die Hand gibt, sich kontinuierlich anzupassen und sich von innen heraus neu zu erfinden. Oder sich aber dann bei Bedarf doch radikal zu ändern. LeSS, Scrum@Scale, Spotify? Ich sehe derzeit nichts, was als Leitfaden für ein großes Unternehmen mit sowohl digitalen als auch nicht-digitalen Abläufen dienen kann. Vielleicht ist es an der Zeit, einen solchen zu entwickeln.