Alles egal: das Skalierungsframework macht keinen Unterschied

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]

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.  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!

 

---