SAFe to go

Alle unabhängigen Untersuchungen ergeben, dass die Einführung von SAFe die in Unternehmen typischen Trägheiten und Unzulänglichkeiten verstärkt und nicht agiler oder effizienter macht.¹ ² Die mangelnde Wirkung teilen sich allerdings alle Frameworks, die agile Methoden zu skalieren versuchen.

Dieser Text nutzt die Vorarbeit eines kollaborativen Textes ‘Information for decision-makers considering the SAFe framework‘ und erweitert diese Informationen um eigene Recherchen. Das eher niederfrequente Diskussionsforum der losen Gruppe ist hier. Stefan Knecht hat u.a. eine RTE-Zertifizierung und hinreichende Erfahrung in mehreren SAFe-Umgebungen.

Auch die industrieübergreifende Expertengruppe DACH30-Arbeitsgruppe agiler Experten größerer deutschsprachiger Unternehmen fasst die in ihrem Netzwerk aus über 30 deutschsprachigen Konzernen und mehr als zweihundert Transformationen mit SAFe kritisch zusammen: “(…) wenn lean-agile Prinzipien nicht lebbar sind (…) ist eine Agilisierung und die Organisation nach Wertströmen unerreichbar”. Kleine Erfolge würden häufig “wegen ‘Framework-Dogmatismus’ Schaden nehmen”.³ Das ist eine Warnung, keine Empfehlung?

Das Ziel ist business agility — was genau ist das?

Das Ziel von SAFe und einer wirksamen Transformation ist Business Agility⁴ Was genau das ist, liest sich im englischen Original enorm süffig:

“The ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative, digitally enabled business solutions.”

Nun kann nicht jede*r fliessend Englisch. Übersetzt ins Deutsche und wenn man aus dem business denglisch die Luft ablässt, wird es schnell profaner:

„Die Fähigkeit, im digitalen Zeitalter wettbewerbsfähig zu gedeihen, indem man mit innovativen, digital gestützten Lösungen schnell auf Marktveränderungen und neue Chancen reagiert.“

Das ist altertümliche Sprache. Mag an der Übersetzung liegen, wird auch mit mehr sprachlicher Mühe nicht gehaltvoller. Wie genau kann das geschehen, was muss alles eingetreten sein, damit diese Business Agility⁴ sich zeigt? (Bleiben wir gleich im Deutschen, der englische Originaltext ist in der Fussnote.)

Business Agility erfordert, dass jeder Teil einer Organisation — nicht nur die IT — die Prinzipien von Lean und Agile übernimmt. Dazu gehören die Führung, der Betrieb, die Personalabteilung, das Finanzwesen und andere Geschäftsbereiche.⁵

Das ist nun nichts weniger als alles, das gesamte Unternehmen auf links gedreht. Ist das noch halbwegs realistisch? Sechs Punkte fordert SAFe. Übersetzt man auch diese⁶ nüchtern wie hier ins Deutsche, dann liest es sich weit weniger schmissig und potent — rechts die Kommentierung:

Lean-Agile Führung – Führungspersonen fördern eine Kultur des kontinuierlichen Lernens und der Anpassungsfähigkeit	die Fähigkeit zu lernen und sich anzupassen haben alle Lebewesen, sonst wären sie längst tot
Bereitstellung von Unternehmenslösungen: Die Organisation baut und entwickelt große Systeme effizient	so korrekt wie trivial: ineffiziente Unternehmen verlieren im Wettbewerb und gehen pleite. Ganz ohne SAFe.
Agile Produktlieferung: kundenorientiertes Produktmanagement sorgt für schnelle Reaktion auf Kundenwünsche und die Lieferung von Wert	leider etwas schlicht: wird produziert, was nicht gewünscht ist, dann wird es nicht gekauft (unnütz wie der Heizer auf der E-Lok)
Schlankes Portfoliomanagement: Abstimmung von Strategie, Investition und Ausführung zur Wertoptimierung	ja klar, wie denn auch sonst …? Das ist die Definition von Portfoliomanagement, BWL-Grundstudium.
Organisatorische Agilität – Die Teams arbeiten flexibel und optimieren den Fluss über Wertströme (value streams)	‘Wertstrom’ ist ein Neologismus, eine Wortneuschöpfung. Leider ohne tiefere Bedeutung. SAFe jedenfalls nimmt den Begriff und definiert ihn nicht weiter.
Kultur des kontinuierlichen Lernens – eine Haltung ständiger Verbesserung und Innovation	im Englischen heisst es relentless = schonungslos – das schmeckt schon ein wenig anders

Funktioniert SAFe? Wer es erlebt hat, schweigt.

Auffällig ist auch: SAFe wird von keinem der global-kommerziellen Software-/Plattformunternehmen wie Facebook, Google, Netflix oder Microsoft eingesetzt. Von einem ‘Industriestandard’, den SAI in Eigenwerbung für SAFe in Anspruch nimmt, kann also keine Rede sein. Ungefähr ein Viertel der Unternehmen, die irgendein Framework einsetzen, nutzt SAFe, ein Fünftel Scrum@Scale, wie aus einer jährlichen Befragung⁷ hervorgeht. Über die Zeit nimmt die Anzahl der SAFe-Follower eher zu als ab. Ein gutes Drittel scheint keinerlei Framework zu verwenden oder selbst ein Modell der innerbetrieblichen Zusammenarbeit zu entwickeln. Allerdings ist die Erhebung alles andere als repräsentativ⁸ — doch bessere Zahlen sind nicht verfügbar: was also tatsächlich in der Welt geschieht, bleibt im Dunklen und öffnet doch weiten Raum für Dichtung und alternative Wahrheiten. Auch sind freiwillige Erfolgsmeldungen aus größeren industriell-mechatronischen Fertigungsbetrieben, in denen Maschinen erst mit integrierter Software verkäufliche Produkte ergeben, eher dürr. Bei BOSCH oder Mercedes-Benz heisst es, sei SAFe im Einsatz. Werden damit auch ganze Autos oder Teile daraus erfolgreich und schneller als mit konventionellen PEPs (Produktentwicklungsprozessen) entwickelt? Es kommt darauf an, wer antworten darf. Die ‘offiziellen’ Erfolgsmeldungen der SAI Inc., die SAFe kommerziell entwickelt und druckvoll vermarktet, sind ebenso überschwänglich wie nicht überprüfbar, die Faktenlage ist undurchsichtig. Das Fehlen unabhängiger Forschung zur Wirksamkeit von SAFe wie LeSS ist um so auffälliger, da der publication bias erfolgreiche Umsetzungen systematisch bevorzugt: weil weder die Urheber der Methoden noch die untersuchten Unternehmen ein Interesse daran haben, die dunklen Ecken und Fehlschläge auszuleuchten: es werden so ausschliesslich gelingende Transformationen berichtet, fehlgeschlagene und stecken gebliebene Reformen haben keinen Neuigkeitswert und stören im Marketing. Ein fantastisches Beispiel für den survivor bias, magisches Denken und cargo cult.

Verrückte Idee: was in kleinen Software-Teams klappt … skaliert für ganze Unternehmen?

Der Herkunftskontext agiler Praktiken und Zusammenarbeitsformate ist die schnellere Herstellung zuverlässig funktionierender Software. So sind ausnahmslos alle methodisch aktualisierten Skalierungsframeworks um die Realitäten von Softwareunternehmen konstruiert.⁹ Diese Methoden und Sozialdynamiken entstanden um wasserfall-ähnliche, deterministische Planung flexibler und realistischer zu machen, um schneller Nützliches liefern und schneller in Rechnung stellen zu können. Agilität hat ja mit New Work oder artgerechter Haltung nichts zu tun: es geht um Effizienz — und das ist in Ordnung so im besten Kapitalismus, den wir uns ausgesucht haben. Im idealen Kontext eines ‘agile sweet spot’¹⁰ entwickeln kleine und am gleichen Ort zusammen arbeitende Teams mit weniger als 50 Personen nicht-lebenswichtige Software¹¹ und halten sich dabei an wenige Regeln und Abläufe, die im Scrum Guide trocken aufgeschrieben sind. Die Softwerker oder mindestens eine Proxy-Person als Vertreter der Entwickler haben unmittelbaren und regelmässigen Zugang zu realen Nutzern, prospektiven Kunden und wirtschaftlich kalkulierenden Kaufleuten. ‘Prospektive’ Kunden sind dabei nicht irgendwelche fiktiv-idealisierten ‘Personae’ sondern reale Einkäufer oder Personen, die Rechnungen auch gegenzeichnen können. Entwickler zeigen regelmässig, was sie aus Wünschen und Erwartungen in Software gegossen haben — und steuern ohne Murren schnell um, wenn Kundenbedürfnisse oder ‘der Markt’ sich drehen. Soweit das Wunschdenken und die Theorie.

SAFe in der Mechatronik? Da trennen sich die Geister.

Methodische Erweiterungen für die spezifischen Randbedingungen in fertigenden Industrien oder der Mechatronik sind bislang in kommerzialisierten Skalierungsmodellen nicht abgebildet. Ebensowenig sind stage-gate Verfahren wie klassisch-deterministische Produktentwicklungskaskaden von der Vorentwicklung bis in die Serie weder in SAFe noch LeSS umgesetzt. Das mag auch daran liegen, dass die Grundtugenden agiler Praktiken schlecht einhergehen mit präskriptiven Methoden, zeitlichen Vorläufen und Randbedingung industrieller Fertigung. Die Realität ist härter als der Seitenübergang in PowerPoint.

Muster des Scheiterns

Al Shalloway, ein ehemaliger SAFe Principal Contributor und erster SAFe Program Consultant Trainer (SPCT) beschrieb¹² das Muster scheiternder SAFe-Implementierungen. Demnach laufen die ersten zwei, drei PI Planungen rund, Ergebnisse stellten sich ein. Bei manchen Unternehmen stagniere der Fortschritt, andere seien zufrieden mit den (meist überschaubaren) Verbesserungen. Wird SAFe aufgegeben, dann läge das entweder daran, dass neue C-level Personen die Unterstützung aufgeben oder SAFe sich zu einem Push-System wandelt und die Resultate damit schlechter werden.

“(…) SAFe ist ein verbesserter Wasserfall”¹³ und “bietet gerade genug, um anzufangen — aber nicht genug, um sich wirklich ständig zu verbessern.”¹⁴

Nach sechs Jahren intensiver Mitarbeit bei SAI wendete sich Shalloway 2018 desillusioniert von SAFe ab, da “(…) SAFe wesentlich komplexer wurde, als es sein müsste” wobei es “(…) ein guter Start sei, ganzheitliche Sichtweise, unternehmensweite Ausrichtung und Einführung in agile Prinzipien” böte.

Es gibt also kein evidentes Verfahren um ‘Agilität’ von wenigen Teams zu business agility für ganze Unternehmen zu skalieren. Auch gibt es keinen schlüssig beschriebenen und erfolgreichen Versuch, funktionierende Konzepte anderer Unternehmen für andere Organisationen zu kopieren. Das gerne genannte Spotify-Modell ist weder ein Modell, noch ist oder war es bei Spotify jemals wie beschrieben im Einsatz:¹⁵ es ist ein Gespenst. Nur hat sich das offenbar nicht herumgesprochen: 2017 und inspiriert von Spotify und dem verlautbart erfolgreichen Umbau der beiden Banken ING und ABN AMRO startete die ANZ Bank als zweitgrößtes Finanzinstitut in Australien und Neuseeland eine SAFe-Transformation.¹⁶ Ende 2018 sollte die full configuration geplant erreicht werden.¹⁷, ¹⁸ Teams wurden trainiert und dann in einer einzigen Woche nach SAFe-Vorgaben ein erster ART gestartet.¹⁹ Die Reformen schlugen allerdings ins Gegenteil²⁰: nach mehr als zwanzig Prozent Gewinnsteigerung in der ersten Hälfte 2017 wurden mit der SAFe-Einführung die ANZ-Systeme zur Bewilligung von Wohnungsbaudarlehen zu den langsamsten in Australien, ANZ verlor einen beträchtlichen Anteil des 2-Milliarden-Dollar-Hypothekenmarktes, der Aktienkurs sank um 17 Prozent.

Auch als die U.S. Air Force SAFe für die Softwareentwicklung einführte, blieben die versprochenen Effekte aus. Trotz intensiver und kostenlosen Beratung stoppte der ‘Chief Software Officer’ die weitere SAFe-Implementierung und nutzt heute einen generischen Methodenmix in der Softwareentwicklung und kein Framework:

“Softwareentwicklungsprogrammen wird nachdrücklich abgeraten, starre, präskriptive Frameworks wie SAFe zu verwenden.” — Nicholas Chaillan, U.S. Air Force and Space Force Chief Software Officer²¹ ²².

Auch das Management von Volvo Cars entschied Anfang 2017²³, SAFe in der Softwareentwicklung einzuführen, da “Autos eher Computer auf Rädern seien”²⁴. Eine gewaltige Reform: 40.000 Mitarbeitende produzieren 700.000 Autos pro Jahr, rund 10.000 Softwareingenieurinnen entwickeln 150 Millionen Zeilen Code für die rollenden Rechner. Im September 2022 gab dann eine ganze Volvo-Abteilung mit 11 Teams und mehr als 100 Softwareingenieuren, UX-/Grafikdesignern SAFe wieder auf: SAFe “lege den Fokus auf Prozesse und einen hierarchischen Top-Down-Ansatz und erweitere das Organisationsdiagramm um zusätzliche Ebenen”²⁵, wodurch technische Exzellenz verloren ginge. Das ist das, was man meint besonders gut zu können.

“Es war offensichtlich, dass SAFe keinerlei Nutzen brachte. Wir taten alle nur so, als ob wir SAFe machten.” — Ryan Nel, leitender Softwareingenieur bei Volvo Cars²⁶

Stille in der Fankurve

Selbst prominente Agilisten, Trainer und fellows, die mit SAFe allesamt ordentliche Umsätze machten, kündigten öffentlich die Gefolgschaft, im Tenor mit recht ähnlichen Begründungen:

SAFe “(…) ist zu groß, (…) definiert zu viele Rollen, Schichten, Abläufe”, “(…) ist zu sehr auf Zertifizierungen und Training fokussiert” und “(…) schafft Berater, für die SAFe die Lösung jedes Problemes ist” — Bob Galen, ehemaliger SAFe SPC²⁷

“(…) all die Prinzipien, die wir in Lean UX eingebaut haben, scheinen in SAFe nicht zu existieren.” und “SAFe is nicht agile” — Jeff Gothelf, Mitbegründer von Lean UX, das in SAFe 4.5 integriert wurde²⁸

Viele Erstunterzeichner des agilen Manifest distanzieren sich längst von SAFe, darunter Ron Jeffries, Andy Hunt, Martin Fowler, Alistair Cockburn oder Mike Beedle und auch Jeff Sutherland²⁹, Co-Autor des Scrum Guide, und mit Ken Schwaber Mitbegründer von Scrum:

“Frameworks wie SAFe können eine gute Ausgangsbasis für Unternehmen sein, die Agile nicht verstehen, aber sie sind nicht mit dem Scrum Guide vereinbar und schreiben Fehlfunktionen fest, die Teams jahrelang lähmen können.” (…) “unSAFe at any speed” — Ken Schwaber³⁰, Co-Autor des Scrum Guide, Mitbegründer von Scrum

Wirtschaftlich denken — wie die Heuschrecken!

Trotz fehlender Wirkungsbelege und dürftiger Faktenlage wird viel Geld mit einem florierenden Geschäftsmodell gemacht. Bei mehreren (SAFe-)Rollen kann das für Unternehmen wie Berater teuer werden: mit bei einer kleinen Versionserhöhung von etwa v6 auf 6.1 sollen sich alle in SAFe definierten Rollen wie RTEs, POs usw. kostenpflichtig nachzertifizieren. Viel Neues ist da selten zu prüfen. Ob sie das tun bleibt ihnen selbst überlassen.

Weshalb aber sollte ein übersichtlich kleines Unternehmen, das nichts wirklich Bahnbrechendes erfindet und im Wesentlichen vorhandene agile Praktiken und Methoden bündelt und weltweit druckvoll und geschickt vermarktet, einen Investor benötigen? Kaum bekannt ist, dass Scaled Agile Inc. von venture capital getrieben ist und damit auch dessen Regeln folgen muss. In drei Finanzierungsrunden wurden mehr als 700.000 US$ eingeworben und im November 2021 vom US-Beteiligungsunternehmen Leeds Equity (4 Mrd. USD Portfolio) an die französische Investmentfirma Eurazeo (32 Mrd. € Portfolio) als “mittelgroßes Buyout” verkauft wurde. Eurazeo hält seit dem eine Mehrheitsbeteiligung für 300 Mio. US$.³¹ Wie kann das aufgehen? Investoren geben kein Geld, wenn nicht ein massiver Hebel erwartet wird, eine Verzehnfachung ist die übliche Wette. Wie können sich also die investierten 300 Mio auf 3 Milliarden US$ vervielfachen? Den größeren Posten der Trainingsumsätze machen SAFe-Partner, die Lizenzgebühren abführen. Das ist ein einträgliches Geschäft solange Unternehmenskunden den Nutzenversprechen glauben, Mitarbeiterinnen zuerst durch penibel standardisierte Trainings und dann in Rollenzertifizierungen schicken.

Zumindest folgen Dean Leffingwell und Scaled Agile damit ihrem eigenen Prinzip #1 – Nimm eine wirtschaftliche Sichtweise ein. Das wenigstens ist erledigt. Der Wirksamkeitsnachweis der Veränderungsrezepte und das Nutzenversprechen noch nicht.

* * *

Dieser Text nutzt die Vorarbeit eines kollaborativ gepflegten Textes Information for decision-makers considering the SAFe framework und erweitert diese Informationen um eigene Recherchen. Das eher niederfrequente Diskussionsforum der losen Gruppe ist hier ↩︎
Edison, H., Wang, X., & Conboy, K. (2022). Comparing Methods for Large-Scale Agile Software Development: A Systematic Literature Review. IEEE Transactions on Software Engineering, 48(8), 2709–2731. DOI ↩︎
Linked-In Posting von Stefan Waschk am 29.6.22, URL ↩︎
’Business Agility ist in SAFe und Englisch definiert als “The ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative, digitally enabled business solutions.” ↩︎
Business Agility requires every part of an organization — not just IT — to adopt Lean and Agile principles. This includes leadership, operations, HR, finance, and other business units. ↩︎
Die sechs Forderungen um Business Agility zu erreichen lauten im Englischen:
1. Lean-Agile Leadership – Leaders foster a culture of continuous learning and adaptability;
2. Enterprise Solution Delivery – The organization builds and evolves large-scale systems efficiently;
3. Agile Product Delivery – Customer-centric product management ensures fast feedback and value delivery;
4. Lean Portfolio Management (LPM) – Aligns strategy, investment, and execution to optimize value;
5. Organizational Agility – Teams operate flexibly, optimizing flow across value streams und
6. Continuous Learning Culture – A mindset of relentless improvement and innovation. ↩︎
17th Annual State of Agile Report. 2023. URL; die Zitate sind auf Seite 18 ↩︎
Der ‘17th Annual State of Agile Report’ ist eine Onlinebefragung und keineswegs repräsentativ. n = 788; 30% der Befragten arbeiten in Unternehmen mit mehr als 20.000 Mitarbeitenden und ungefähr ein weiteres Drittel in Unternehmen mit weniger als 1.000 Mitarbeitenden; die Rollen-/Titelbezeichnungen (S. 26) deuten auf selbstdienliches Antwortverhalten. Antwortende aus den USA sind mit etwa der Hälfte der Befragten überproportional repräsentiert. Teilnehmende aus der fertigenden Industrie sind nicht ausgewiesen. ↩︎
Uludağ, Ömer, Abheeshta Putta, Maria Paasivaara, und Florian Matthes. „Evolution of the Agile Scaling Frameworks“. In Agile Processes in Software Engineering and Extreme Programming, herausgegeben von Peggy Gregory, Casper Lassenius, Xiaofeng Wang, und Philippe Kruchten, 419:123–39. Lecture Notes in Business Information Processing. Cham: Springer International Publishing, 2021. DOI. ↩︎
Der Begriff ‘agile sweet spot’ stammt aus: Dingsøyr, T., Moe, N.B., Fægri, T.E., Seim, E.A.: Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation. Empir. Softw. Eng. 23(1), 490–520 (2017). URL ↩︎
mit nicht-lebenswichtiger Software sind Anwendungsfälle gemeint, bei denen es nicht um Leib und Leben geht. Also eher nicht Herzschrittmacher oder Flugabwehrsysteme. ↩︎
Ein Linked-In thread aus 2023 mit mehr als 70 Debattenkommentaren; daraus eine schematische Grafik, die das empirische Erfahrungswissen darstellt ↩︎
Shalloway, Al. am 1.9.2020 auf Twitter: “The more I read ”Team Topologies“ the more I think it’s more appropriate to call SAFe an improved waterfall than it is to call it a poor Agile. Creating ARTs merely accomodates dependencies & is a poor value creation structure. 3 month PIs is not Agile but is better than annual.” ↩︎
Shalloway, Al, am 14.12.2016 auf LinkedIn: Net Objectives’ Approach to SAFe ↩︎
Kniberg, Henry. 7.6.2015. No, I didn’t invent the Spotify model. URL und Lee, Jeremiah. 19.4.2020. Failed SquadGoals – Spotify doesn’t use ’the Spotify model’ and neither should you. URL; “Even at the time we wrote it, we weren’t doing it. It was part ambition, part approximation. People have really struggled to copy something that didn’t really exist.” — Joakim Sundén, agile coach at Spotify 2011–2017. URL Die Umbenennung von Teams und Abteilungen in squads und tribes führte zu Verwirrung und scheiterte; das Matrixmanagement war ineffektiv; den Teams fehlte es an grundlegenden agilen Kompetenzen; als Scale-up-Unternehmen waren die auf Autonomie optimierten Teams suboptimal; ↩︎
Campbell-Pretty, Em. “SAFe from the Trenches @ Agile Australia”. Pretty Agile Blog, 31.8.2017. ³²: Campbell-Pretty, Em. The 6-Day SAFe Quick-Start with Self-Selecting Teams. Pretty Agile Blog, 29.11.2016
Pressemeldung. “ANZ to implement Scaled Agile approach to transform customer experience”, 5.2.2017. ↩︎
Nott, George. “ANZ Bank Goes All-in with ‘Scaled Agile’ Approach”. CIO, 2017. ↩︎
campbell_anz2 ↩︎
Hyland, Anne. “Shayne’s world: How Shayne Elliott’s ‘agile’ ANZ got stuck”, 27.8.2022, Sydney Morning Herald. ↩︎
Linked-in post von Nicholas Chaillan mit Verweis auf ein “Ask Me Anything Event” am 21.2.2020 und ein ‘slide 33’ – das allerdings unter dieser URL ebensowenig auffindbar ist wie das PDF eines “Memorandum Preferred Agile Framework” vom 21.12.2019 ↩︎
Nicholas Chaillan sagte am 7.3.21 auf X “SAFe is still anti DevSecOps. Not allowed in my teams.” ↩︎
Bergquist, Jacob, und Navid Gordani. “Large-Scale Agile Transformation – A Case Study of Volvo Cars’ Transformation Process”. Gothenburg, 2018. PDF ↩︎
Denning, Steve. “Why And How Volvo Embraces Agile At Scale”. Forbes, 26.1.20. ↩︎
Ljung, Anna, und Johanna Udesen. “The role of the first line manager in a Scaled Agile organization – A Case Study at Volvo Cars Corporation”. Gothenburg, 2019. PDF ↩︎
Ryan Nel [@ryannel_dev]. “@allenholub My Department at Volvo Has Just Dropped SAFe. It Became Obvious That It Wasn’t Adding Any Value and We Were All Just ‘Pretending to Follow It’.” Twitter, 22.9.22. ↩︎
Bob Galen am 22.4.2019 auf seinem Blog “SAFe no longer – my final farewell” ↩︎
Jeff Gothelf sagt am 10.5.2021 auf seinem Blog SAFe is not Agile; “In short, SAFe is not agile.” ↩︎
Sutherland, Jeff am 22.1.2015 in einem Linkedin-Posting What Silicon Valley Needs ↩︎
Schwaber, Ken am 6.8.2013 als Überschrift eines Blogbeitrages unSAFe at any speed ↩︎
Pressemeldung “EURAZEO TO INVEST IN SCALED AGILE”, 15.11.2021. PDF ↩︎