digitalien.org — Stefan Knecht

Alles egal: das Skalierungsframework macht keinen Unterschied

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 Russo[1], die sowohl statistisch robuste[2] 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 Russo[1] 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 signifikante[3] 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 Methode 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 nun keine Premiere sondern länglich bekannt, wenn man es denn wissen wollte.[5]

Um vergleichbare Daten erheben zu können, definieren die Autoren Begriffe: ’Skalierung’ bezieht sich[1] auf kompliziertere Softwareprodukte[6] 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-scale[8] 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 Softwareumgebungen[10] aus fünf Faktoren zusammengesetzt:

  1. 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
  2. Stakeholder-Concern erfasst, inwieweit Teams verstehen, was ihren Stakeholdern wichtig ist (Zusammenarbeit, gemeinsame Ziele, Qualität der Sprint-Reviews, Wertorientierung)
  3. 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)
  4. Teamautonomie spiegelt den Spielraum der Teams, ihre eigene Arbeit zu organisieren (Selbstmanagement, Querschnittsfunktionalität)
  5. 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 hört 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 demnach[1] 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.

Die von Fundamental-Agilisten gerne geäusserte Meinung »leichtgewichtige Frameworks wie LeSS sind besser als stark präskriptive wie SAFe«[11] [12] kann aus den Daten[1] nicht bestätigt werden.[13] Schlangenöl hilft für und gegen alles!

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 Manifests[14] so 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. Ein Steakholder 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!

 

  1. 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.  ↩
  2. inferenzstatistische Analysen, einschließlich Varianzanalyse und multipler linearer Regression, um signifikante Unterschiede zu ermitteln; Kontrollvariablen: Teamerfahrung und Größe der Organisation  ↩
  3. das Ausmass, zu dem ein Ergebnis nicht zufällig ist  ↩
  4. 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)  ↩
  5. 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.  ↩
  6. Für mechatronische und industrielle Fertigung erklärt sich keines der betrachteten Skalierungsframeworks ausdrücklich zuständig.  ↩
  7. 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.  ↩
  8. 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.  ↩
  9. 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.  ↩
  10. 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.  ↩
  11. Wolpers S (2023) SAFe’s NPS Score as a Scaling Framework Is –56 According to 505 Survey Participants. URL  ↩
  12. Hinshelwood M (2023) The SAFe delusion: Information for decision-makers considering the SAFe framework. URL  ↩
  13. 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«  ↩
  14. das Agile Manifest in seiner Urform ist hier zu finden. Seit mehr als zwanzig Jahren.  ↩