LeSS oder SAFe versprechen die Skalierung der im Kleinen funktionierenden agilen Methoden und Praktiken auf größere Vorhaben oder ganze Unternehmen. Als zeitsparende und methodisch effektive frameworks werden sie wie Bauanleitungen für Transformationen zu mehr Kundennähe und schnellerer Lieferung vermarktet. So wird SAFe 6.1 mit einem ebenso eindrucksvollen wie aggressiven Nutzenversprechen angeboten:
Das sensationelle Nutzenversprechen, der USP von SAFe v6.1
sind Produktivitätssteigerungen von 20–50% möglich und
Mitarbeiter engagieren sich 10–50% mehr
Die Mächtigkeit dieser als Nutzenversprechen avisierten Verbesserungen ist also mehr als verblüffend: Change Manager wie Projektleiter·innen, die sich professionell mit zähen Verhaltensanpassungen von Menschen in Unternehmen plagen, wären mit einstelligen Verbesserungen schon mehr als zufrieden: geschieht nachhaltige Veränderung doch beobachtbar überwiegend im Kriechgang. Was Scaled Agile Inc., das venture capital-finanzierte US-Unternehmen hinter SAFe, verspricht, sind hingegen atemberaubende Aussichten: jeden Prozessoptimierer, jede Controllerin muss es da instantan vom Drehstuhl reissen! So beeindruckend diese Zahlen klingen, so fragwürdig ist leider ihre Herkunft und Qualität. Die Daten stammen aus etwa fünfzig sogenannten self-assessments2, Selbsteinschätzungen von Unternehmen, die SAFe einsetzen. Keine Randomisierung, kein Kontrollversuch, keine Vergleichsgruppe — ob man vielleicht die Rohdaten genauer betrachten könne …? Fehlanzeige. Wer etwas nachdrücklicher recherchiert, erfährt nach angemessener Wartezeit: Mehr Belege gibt es nicht. Die Werte seien aus customer stories abgeleitet, heisst es auf Anfrage bei Scaled Agile Inc. Mehr als achtzig Erfolgsgeschichten sind zusammengetragen.2 Zieht man Doubletten ab und Unternehmen, die es trotz mit oder wegen SAFe nicht mehr gibt, dann bleiben mindestens fünfzig Erfolgsgeschichten Rohdaten sind nicht verfügbar. Die sagenhaften Erfolgszahlen von SAFe beruhen also auf Interviews, deren Methodik freundlich als ‘informell’ beschrieben werden kann. Die ‘Daten’, die die Wirksamkeit und das Nutzenversprechen von SAFe belegen, wurden nie unabhängig geprüft. Das hindert SAI Inc. nicht daran, seine Behauptungen als quasi-empirische Wahrheiten zu vermarkten. Das Problem? Interessenkonflikte. Scaled Agile Inc. kontrolliert sowohl das Framework wie die Erfolgsmessung. Das ist ein Problem: ohne belastbare Daten bleibt SAFe ein breitbeiniges Versprechen einer beneidenswert effektiven Marketingmaschine aus Boulder, Colorado, USA.
Ohne Offenheit bleiben Fakten im Dunkeln, und Entscheidungen beruhen auf spekulativen Annahmen und fehlenden Daten. — Auszug aus den SAFe core values3
Diese schmerzhaft fehlende Transparenz hätte sich um ein Haar einstellen können. Auf dem SAFe-Summit Berlin Mitte April 2024 erbot sich mit Marc Rix einer der szeneprominenten methodologists und fellows der der Scaled Agile Inc. die Bereitstellung und unabhängige Prüfung der Rohdaten aus den customer stories zu klären. Ebenso freundlich wie sensationell zog sich die offenbar intensive Klärung bis in den Vorstand der SAI Inc. über Monate. Währenddessen stand für den eher mühsamen Teil der unabhängigen Validierung und Evidenzprüfung Prof. Dr. Tobias Nickel mit Studierenden der TH Deggendorf School of Management bereit. Die gemeinsame Hoffnung war, Korrelation/en zwischen dem Einsatz von SAFe und den vier Nutzendimensionen zu entdecken, vielleicht gar causation — dass also SAFe die Ursache für Verbesserungen ist?
Korrelation und Verursachung sind nicht ganz augenfällig.
Ein Dreivierteljahr später Ernüchterung: es gibt keine Daten. Die customer stories sind alles, was es zur Validieren des versprochenen Nutzens von SAFe gibt. Für eine methodisch saubere Evaluierung ist diese Prosa nicht verwendbar. Zur Entstehung der ‘Daten’ kann. man nur spekulieren. Sitzt da ein·e SAI-Mitarbeiter·in einem Unternehmensmenschen gegenüber, in einem Zoom-Meeting und geht einen strukturierten Fragenkatalog durch? Werden auch neutrale und eher widrige Aussagen der Kunden protokolliert? Finden diese Interviews tatsächlich statt …? Wir wissen es nicht, SAI Inc mag nicht mehr verlautbaren.
Die Plausibilität der behaupteten Verbesserungen liegt auf einem Niveau, das selbst ausgebuffte Werbeagenturen beschämen sollte. SAFe verkauft Hoffnung auf Transformation zäher Gewohnheiten, geliefert wird Storytelling und ein wenig magischer Glauben an ritualisierte Gruppendynamik. Das ist geschickt doch leider weder evident noch strafbar. Für rational agierende Unternehmen, die mit Zahlen und Fakten statt mit Glauben und Hoffnung überleben, bleibt der tatsächliche Nutzen so vage wie die Methodik, die ihn belegen soll.
* * *
‘vorgesehen’ bedeutet: alle Schritte und Vorgaben des Einführungs- und Umsetzungsprogramms werden im Unternehmen, das sich mittels SAFe transformieren will um business agility zu steigern ebenso deterministisch durchlaufen, wie die vorgesehene Anzahl SAFe-Expert·innen trainiert und (kostenpflichtig) regelmässig zertifiziert und eine akkreditierte Beratungsfirma zur Begleitung beauftragt wird. Also all-you-can-eat wenn man so will. Und ja: wie kann der Nutzen auch gehoben werden, wenn nicht EXAKT ALLES GENAU SO gemacht wird, wie das Framework es vorsieht? (Das war Ironie.) ↩︎
Im Original lautet das Zitat: “Without openness, facts are obscure, and decision-making is based on speculative assumptions and a lack of data. No one can fix a secret.” SAFe baut auf den agilen Werten, Prinzipien und Methoden auf. Diese Werte sind, holprig ins Deutsche übersetzt: “gemeinsame Ausrichtung, eingebaute Qualität, Transparenz, Programmausführung und Lean-Agile-Mentalität” ↩︎
Wie Veränderung am Besten geht, wie Wandel kommt und bleibt? Genau weiss das niemand, es gibt mehr Meinungen als Fakten. Eine seltene Ausnahme ist der Preprint einer im Juli 2024 erscheinenden Arbeit von Verwijs und Russo1, die sowohl statistisch robuste2 wie unerwartete Antworten zu einer zähen Glaubensfrage bietet: Was ist das beste Skalierungsframework?
Wann ist SAFe, LeSS oder ein eigener Methodenmix produktiver? Unter welchen Bedingungen sollte man agile Skalierung bleiben lassen? Die Forschungsfrage dieser jüngsten Arbeit von Verwijs und Russo1 lautete …
»Wie werden die Effektivität von agilen Teams und die Zufriedenheit ihrer Stakeholder durch den agilen Skalierungsansatz beeinflusst?«
<tl;dr>Das agile Skalierungsframework hat keinen wesentlichen Einfluss auf die Effektivität von Entwicklungsteams. Zwar gibt es kleine statistisch signifikante3 Unterschiede zwischen den Skalierungsansätzen, doch deren Effektgrößen sind in der Praxis irrelevant.4 Das bedeutet für ausnahmslos alle Ansätze: Frameworks haben vernachlässigbaren Einfluss auf die Effektivität der Entwicklungsteams und die Zufriedenheit der Stakeholder. Die Skalierungsmethode selbst ist also waste, wie es angenehm kurz in lean für etwas heisst, das niemand braucht. Entscheidend sind vielmehr die handfesten Erfahrungen der Entwicklungsteams mit agilen Praktiken und Methoden, also die Kompetenz, das praktische Können. Auch diese Erkenntnis ist länglich bekannt, wenn man es denn wissen wollte.5
Um vergleichbare Daten erheben zu können, definieren die Autoren Begriffe: ’Skalierung’ bezieht sich1 auf kompliziertere Softwareprodukte6 mit mindestens sechs Teams bei Teamgrößen von sechs bis sieben Personen.7 Vereinfacht: es arbeiten mehr als 50 Entwicklerinnen zusammen an einem Produkt. Als large-scale gilt, wenn 2–9 Teams beteiligt sind, bei mehr als zehn Teams werden Vorhaben als very large-scale8 bezeichnet. ‘Stakeholder’ ist dabei jeder, der einen Anteil (stake) am Endprodukt hat und davon im weiteren Sinn betroffen ist. Die Zufriedenheit der Stakeholder drückt aus, ob jene kriegen, was sie bestellten. Team effectiveness ist definiert als Komposit aus stakeholder satisfaction und team morale oder job satisfaction. Das ist plausibel, von Unternehmen, Branche und Umfeld unabhängig und ermöglicht damit den Vergleich über die breite Stichprobe, aus der die experimentellen Daten stammen. Als Nebenprodukt der Studie gibt es für diese Messgrößen sogar einen validierten und kostenlosen Fragebogen. Die Selbsteinstufung von Teams kann darin um die Stakeholder-Zufriedenheit erweitert werden.9 Nach diesem Ansatz ist die Effektivität von Scrum-Teams in Softwareumgebungen10 aus fünf Faktoren zusammengesetzt:
Reaktionsfähigkeit als die Fähigkeit von Teams, schnell auf neue Bedürfnisse und Anforderungen von Stakeholdern zu reagieren (Release-Häufigkeit, Release-Automatisierung, Verfeinerungen / refinements
Stakeholder-Concern erfasst, inwieweit Teams verstehen, was ihren Stakeholdern wichtig ist (Zusammenarbeit, gemeinsame Ziele, Qualität der Sprint-Reviews, Wertorientierung)
Kontinuierliche Verbesserung meint das Ausmaß, in dem sich Entwicklungsteams in Prozessen kontinuierlicher Verbesserung engagieren und die Sicherheit haben, dies zu tun (psychologische Sicherheit, Sorge um Qualität, gemeinsames Lernen, Verwendung von Kennzahlen, Lernumgebung)
Teamautonomie spiegelt den Spielraum der Teams, ihre eigene Arbeit zu organisieren (Selbstmanagement, Querschnittsfunktionalität)
Unterstützung durch Führungskräfte
Validiert wurde dieses Modell unter einschränkenden Bedingungen: (a) der kompetente Einsatz von Scrum in erfahrenen Teams (b) in einer reinen Softwareumgebung (c) bei gemäßen Teamgrößen und -konfigurationen.
Den größten Effektbeitrag für die Teameffektivität hat die Erfahrung der Entwicklerinnen mit agilen Praktiken und Methoden. Das lässt sich altbacken an — ist es aber nicht: Erfahrung ist die Summe der durch stetiges Lernen erworbene Kenntnisse und Verhaltensweisen, ein Vertrautsein mit Etwas, die Leichtigkeit etwas Gewohntes zu tun — keineswegs die Theorie, Prozessvorgaben, Rituale oder deliverables eines Prozess- oder Skalierungsframeworks.
Überraschenderweise unerheblich für die Teameffektivität ist demnach1 die Unternehmensgröße. Ebenso unterscheidet sich auch die Unterstützung der Teams durch Management und/oder Führungskräfte nicht über die Unternehmensgröße. Irritierend ist: SAFe hat einen signifikant negativen Einfluss auf die Variable stakeholder concern und Teamautonomie — doch keine relevante Effektgröße. Interpretieren könnte man das als: »je mehr SAFe, um so weniger wird beachtet, was wirklich Wert stiftet«. Ja, das schmeckt nach cargo cult und magischem Denken. Die von Fundamental-Agilisten gerne geäusserte Meinung »leichtgewichtige Frameworks wie LeSS sind besser als stark präskriptive wie SAFe«1112 kann aus den Daten1 nicht bestätigt werden.13
Im Sinne der Forschungsfrage ist es ist gleichgültig, welches Framework eingesetzt wird weil alle gleichermassen wirkungsarm sind
Die Autoren raten abschliessend: statt Energie auf die penible, regeltreue Umsetzung (by the book) eines Frameworks zu geben, sollten skalierungswillige Unternehmen die einfacheren Grundsätze des Agilen Manifests14so gut als möglich umsetzen. Wenn es denn unbedingt ein Framework sein soll, dann eines, das die vorhandene Struktur, Kultur und Kompetenzen reflektiert. So mag das kompliziertere, präskriptiv-starre, trainings- und beraterlastige SAFe taugen für hochregulierte, hierarchische Konzernumgebungen mit geringer Erfahrung im agilen Miteinander und gut gefüllter Transformationskasse. Unternehmen, deren Entwicklerinnen agile Praxiserfahrung haben, skalieren sich zu größeren Vorhaben eher mit dem leichtgewichtigeren Scrum of Scrums, LeSS oder entwickeln eine eigene, realistisch an die vorhandenen Fähigkeiten angepasste ‘Hausmethode’.
Im Kleingedruckten der Eingangsbedingungen erwarten jedoch alle Ansätze bereits vor der Implementierung funktionierende agile Teams. Ohne robuste agile Grundkompetenzen werden aus release trains schnell release trams: während der output sich in Methodentreue überschlägt, stottert der outcome.
Weiters wird Praktikern unabhängig vom Skalierungsansatz empfohlen, die Zufriedenheit der Stakeholder und die Effektivität der Teams laufend zu überwachen. Relentless improvement nennen das die SAFe-Jünger, PDCA-loop (plan-do-check-act) oder Hausverstand alle anderen.
Was genau diese ‘Kultur’ in Unternehmen sein soll, ist leider ohne akademischen Konsens. »Kultur ist was geschieht, wenn niemand hinsieht« hilft nicht wirklich weiter. Wie ‘mindset’ ist ’Kultur’ ein Kaugummibegriff, der immer dann herhalten muss, wenn es nicht so gut läuft mit dem change. Oder mit dem Framework.
Rasender Stillstand!
* * *
Verwijs, Christiaan, und Daniel Russo. „Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness across Popular Scaling Approaches“. Empirical Software Engineering 29, Nr. 4 (Juli 2024): 75. DOI. Strukturierte qualitative Befragung von n = 15078 Mitarbeitende in 4013 agilen Teams zur Messung ihrer Effektivität, kombiniert mit Zufriedenheitsumfragen bei 1841 Stakeholdern von 529 dieser Teams. ↩︎
inferenzstatistische Analysen, einschließlich Varianzanalyse und multipler linearer Regression, um signifikante Unterschiede zu ermitteln; Kontrollvariablen: Teamerfahrung und Größe der Organisation ↩︎
das Ausmass, zu dem ein Ergebnis nicht zufällig ist ↩︎
Effektgröße (d) setzt den durchschnittlichen Unterschied in Relation zur Varianz, also zur Breite der Verteilung. Effektgrößen werden manchmal als die »Währung der psychologischen Forschung« bezeichnet. Sie drücken aus, wie relevant ein Unterschied zwischen zwei Durchschnittswerten zweier Gruppen ist; Beispiel: der durchschnittliche Größenunterschied zwischen Fichten und Föhren. d = 0,2 → kleine …, d = 0,5 → mittlere …, d = 0,8 → große Effektgröße Quelle: Schäfer, T., & Schwarz, M. A. (2019). The meaningfulness of effect sizes in psychological research: Differences between sub-disciplines and the impact of potential biases. Frontiers in Psychology, 10(813) ↩︎
Almeida, Fernando, und Eduardo Espinheira. „Large-Scale Agile Frameworks: A Comparative Review“. Journal of Applied Sciences, Management and Engineering Technology 2, Nr. 1 (31. März 2021): 16–29. DOI. ↩︎
Für mechatronische und industrielle Fertigung erklärt sich keines der betrachteten Skalierungsframeworks ausdrücklich zuständig. ↩︎
Dikert, Kim, Maria Paasivaara, und Casper Lassenius. „Challenges and Success Factors for Large-Scale Agile Transformations: A Systematic Literature Review“. Journal of Systems and Software 119 (September 2016): 87–108. DOI. ↩︎
Dingsøyr, Torgeir, Tor Erlend Fægri, und Juha Itkonen. „What Is Large in Large-Scale? A Taxonomy of Scale for Agile Software Development“. In Product-Focused Software Process Improvement, herausgegeben von Andreas Jedlitschka, Pasi Kuvaja, Marco Kuhrmann, Tomi Männistö, Jürgen Münch, und Mikko Raatikainen, 8892:273–76. Lecture Notes in Computer Science. Cham: Springer International Publishing, 2014. DOI. ↩︎
Die datenschutzkonforme Abfrage ist so gestaltet, dass Teams ihren eigenen Entwicklungsprozess selbst validieren können und ihre Stakeholder einladen, das ebenso zu tun. Siehe https://www.scrumteamsurvey.org – kostenpflichtige Varianten erlauben den Vergleich zwischen mehreren Teams eines skalierten Projektes und bieten (wer hätte das gedacht!) Beratung und Dienstleistungen an. ↩︎
Verwijs, Christiaan, und Daniel Russo. „A Theory of Scrum Team Effectiveness“. ACM Transactions on Software Engineering and Methodology 32, Nr. 3 (31. Juli 2023): 1–51. DOI. ↩︎
Wolpers S (2023) SAFe’s NPS Score as a Scaling Framework Is –56 According to 505 Survey Participants. URL↩︎
Hinshelwood M (2023) The SAFe delusion: Information for decision-makers considering the SAFe framework. URL↩︎
im Original der Arbeit heisst es »lightweight approaches do not seem to outperform more expansive and prescriptive approaches, which is a prevalent belief among practitioners«↩︎
das Agile Manifest in seiner Urform ist hier zu finden. Seit mehr als zwanzig Jahren. ↩︎
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.12 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”.3 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 Agility4 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 Agility4 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.5
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 diese6 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 Befragung7 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äsentativ8 — 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.9 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’10 entwickeln kleine und am gleichen Ort zusammen arbeitende Teams mit weniger als 50 Personen nicht-lebenswichtige Software11 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) beschrieb12 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”13 und “bietet gerade genug, um anzufangen — aber nicht genug, um sich wirklich ständig zu verbessern.”14
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:15 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.16 Ende 2018 sollte die full configuration geplant erreicht werden.17, 18 Teams wurden trainiert und dann in einer einzigen Woche nach SAFe-Vorgaben ein erster ART gestartet.19 Die Reformen schlugen allerdings ins Gegenteil20: 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 Officer2122.
Auch das Management von Volvo Cars entschied Anfang 201723, SAFe in der Softwareentwicklung einzuführen, da “Autos eher Computer auf Rädern seien”24. 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”25, 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 Cars26
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 SPC27
“(…) 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 wurde28
“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 Schwaber30, 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$.31 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.
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. ↩︎
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.” ↩︎
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; ↩︎
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↩︎
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. ↩︎
