Ich weiß, es ist en vogue, andere Menschen und Dinge zu beschimpfen. Meistens zeigen dabei drei Finger nach hinten. So ist es auch mit dem Scaled Agile Framework (SAFe). Ich habe in letzter Zeit viele SAFe-Bashings gelesen. Auf agilen Konferenzen bestätigen sich die Leute gegenseitig, wie schrecklich SAFe ist. Aber SAFe ist nicht das Problem, ganz im Gegenteil. Lasst uns sehen, warum. Ich schlage eine andere Perspektive vor, um die Tiraden hinter uns zu lassen und vorwärts zu kommen. Denn Vorwärtskommen braucht Agilität und die Agile Community.
Warum SAFe nicht das Problem ist.
Die Probleme mit SAFe sind real. Vier Gründe, warum SAFe nicht die Ursache ist.
Ein Modell führt keine agilen Transformationen durch. Menschen tun es.
Zunächst einmal führen Modelle keine Transformationen durch. Menschen tun das. Es gibt noch viele weitere Gründe, warum SAFe nicht das Problem ist, aber das ist mein Hauptpunkt.
Ja. SAFe ist falsch.
SAFe ist ein Modell. Alle Modelle sind falsch. Modelle sind eine Abstraktion. Sie sind viel weniger als die Realität, sie sind eine Vereinfachung, sie sind … halt falsch. Da SAFe ein Modell ist, ist SAFe falsch. Modelle sind nicht dazu da, völlig richtig zu sein. Wir entwickeln Modelle als Werkzeug für Fachleute. Als Fachleute ergänzen wir die Modelle mit Wissen und Weisheit. Wir interpretieren die Ergebnisse von Modellen im Lichte des jeweiligen Kontextes.
SAFe ist falsch, aber SAFe ist nützlich.
SAFe kann ein nützliches Werkzeug sein. Dazu müssen wir verstehen, dass SAFe ein Modell ist. Und wir müssen die Grenzen von Modellen kennen. Modelle helfen, uns im Unbekannten zurechtzufinden. Sie geben Orientierung. Aber wir müssen jedes Modell mit einem wichtigen Hinweis im Hinterkopf verwenden. Dieser ist: „Warnung: Dies ist ein Modell. Es ist zwar nützlich, aber unvollständig. Es ist eine Abstraktion und kann zu falschen Ergebnissen führen. Verwende es mit Vorsicht.“ Diese Warnung gilt auch für SAFe.
Die anderen Skalierungsmodelle sind auch falsch und nützlich.
Die Aussage “Modelle sind falsch aber nützlich” gilt für alle Skalierungsmodelle. (Manche Modelle nennen sich “Frameworks”. Für meinen Artikel hier bleibe ich bei dem Begriff Modell.) Large Scale Scrum (LeSS) ist auch toll. Scrum@Scale ist nützlich. Ich mag auch Appelos “unfix organizational patterns“. Wenn es um die Komplexität größerer Organisationen geht, gibt es nicht die eine Lösung, die für alles passt. Deshalb sind alle Skalierungsmodelle nützlich. Sie bieten unterschiedliche Antworten für unterschiedliche Situationen. Und obwohl sie alle nützlich sind, sind sie alle Modelle, und sie sind alle falsch.
Warum wir skalierte Agilität brauchen.
Zwei Gründe, warum wir nicht auf agile Zusammenarbeit jenseits der Teams verzichten können.
Wir brauchen Agilität jenseits der Teamebene.
Manche Leute sagen: “Das Problem ist die Skalierung an sich”. Aber Agilität jenseits der Teamebene zu ignorieren ist keine Option. Es gibt viele Argumente dagegen. Grund eins: Angenommen wir arbeiten auf Teamebene nach agilen Werten und Prinzipien. Dann sollten wir uns zwischen den Teams nach denselben Werten und Prinzipien abstimmen. Viele von uns wissen, wie schwierig es ist, auf der Teamebene mit anderen Werten zu arbeiten als der Rest der Organisation. Grund zwei: Die lokale Optimierung in den Teams hilft nicht dem gesamten Wertstrom. Grund drei: Der Hauptgedanke hinter Agilität ist Reaktionsfähigkeit in einem komplexen Umfeld. Diese ist besonders auf organisatorischer Ebene nützlich.
Die Zukunft ohne große Organisationen wird vielleicht nie kommen.
Manche Leute sagen, dass die Zeit der großen Organisationen vorbei ist. Sie sagen, die Zukunft liege in selbstverwalteten Teameinheiten. Ich spreche mich weder dagegen noch dafür aus – aber ich sehe das nicht so bald. Lasst uns also vorerst mit dem arbeiten, was wir jetzt als Organisationen haben.
Warum Scaled Agile von Natur aus unordentlicher ist als Agilität auf Teamebene.
Scaled Agile wird von vielen als schwierig empfunden. Das liegt in der Natur der Sache.
Schnall dich an: Scaled Agile hat eine exponentielle Komplexität.
Scaled Agile ist Agilität mit mehr als einem Team. Das hat eine exponentielle Komplexität. Außerdem sind soziale Systeme nicht-deterministisch. Alles, was mit skalierter Agilität zu tun hat, hat also einen Exponenten und ist nicht deterministisch. Diese exponentielle Komplexität wird nicht verschwinden, egal was wir tun. Wir müssen uns also damit auseinandersetzen, wenn unsere Organisation größer als ein Team ist.
Scrum kann schlecht sein. Skaliertes Scrum kann in der zweiten Potenz schlecht sein.
Ja, SAFe-Implementierungen können in der Tat schlecht sein. Schlecht hoch zwei – wegen der exponentiellen Komplexität. Aber das ist nicht die Schuld von SAFe. Wir alle kennen Scrum-Implementierungen, die schlecht sind. Aber wir geben nicht Scrum die Schuld dafür. (Nebenbei bemerkt: Ja, manche Leute geben Scrum die Schuld und bieten Kanban als Lösung an. Doch Scrum und Kanban sind ein glückliches Ehepaar. Jeder der beiden hasst es, wenn wir einen der beiden als “den besseren” bezeichnen. Weil sie als Paar so gut funktionieren.) Gutes Scrum braucht Übung, viel Übung. Das Gleiche gilt für Scaled Agile. Hinzu kommt, dass bei Scaled Agile alles mit einem Exponenten versehen ist. Wir brauchen exponentiell mehr Übung. Die Probleme sind exponentiell größer. Es ist exponentiell schwieriger, mit 100 Leuten zu einem gemeinsamen Verständnis zu kommen. Die agile Transformation ist exponentiell unordentlicher. Das ist niemandes Schuld. Das ist die Folge von größeren sozialen Systemen. Dennoch brauchen wir Antworten für skalierte Agilität (siehe oben). Wir müssen uns mit dieser Komplexität auseinandersetzen. Ignorieren ist keine Option. Das bedeutet, dass wir mehr Zeit investieren müssen. Das es mehr Geld kostet. Dass es länger dauert, bis wir die Ergebnisse sehen, die wir uns erhoffen.
Die Lösung: Wissende Nutzer von skalierten agilen Modellen und eine ernsthafte Agile Transformation.
Neun Tips, um trotz der quadratischen Komplexität von Scaled Agile eine agile SAFe Implementierung zu erhalten.
Skalierungsmodelle im Lichte der agilen Werte und Prinzipien verwenden.
Ein Modell ist eine Abstraktion. Wir entfernen in einem Modell einen Großteil der Realität. Wenn wir ein Modell verwenden, um Rückschlüsse auf die Realität zu ziehen, müssen wir diese Realität wieder hinzufügen. Um ein agiles Modell nützlich zu machen, müssen wir es im Lichte von zwei Dingen interpretieren. Erstens: Wir müssen es im Lichte der agilen Werte und Prinzipien interpretieren. Zweitens: Wir müssen wir es im Hinblick auf unsere eigene Organisation interpretieren. Das Mindset und die Interpretation bestimmen, welche Wirklichkeit wir aus aus einem Modell machen. Beispiel: Ein Daily Scrum kann ein Reporting-Meeting oder ein Ereignis zur Selbstverwaltung sein. Das hängt von uns Teammitgliedern ab. Das Gleiche gilt für SAFe: Die PI-Planung kann in ein Gantt-Diagramm münden. Aber es kann auch ein großartiges gemeinsames Product Backlog Refinement sein. Es kommt auf uns an. Eine Tirade wie “SAFe: A Waterfall Pig with Agile Lipstick” zeigt, wie man SAFe in Richtung Wasserfall interpretieren kann. Wenn man will. Es geht auch andersherum. Es kommt darauf an, wie wir die Dinge sehen wollen.
Betrachte SAFe nicht als ein Rahmenwerk wie Scrum. Betrachte SAFe als eine Enzyklopädie.
SAFe nennt sich “Framework”. Scrum nennt auch “Framework”. Die Verwendung desselben Begriffs führt in die Irre, dass Scrum und SAFe so etwas wie dasselbe sind. Das sind sie aber nicht. Scrum ist ein Rahmenwerk, in dem man die Grundelemente nicht entfernen sollte. SAFe ist eine Enzyklopädie von Mustern, bei der eine bewusste Auswahl essentiell ist. Wir müssen das Konzept der Enzyklopädie verstehen. Dann können wir SAFe richtig einsetzen und damit erfolgreich sein.
Habe fundierte Kenntnisse in Scrum, Kanban, etc.
Als Enzyklopädie geht SAFe bei den Artikeln nicht in die Tiefe. So ist beispielsweise Scrum ist ein ganzes Wissensgebiet für sich. Das Gleiche gilt für Kanban oder Design Thinking. Kein Artikel in SAFe ersetzt den “Body of Knowledge“, auf den er verweist. Deshalb brauchen wir fundierte Kenntnisse der Modelle, die wir im Rahmen von Scaled Agile nutzen. Selten hat eine einzige Person all dieses Wissen. Die Lösung ist ein interdisziplinäres Team, das in der Summe die tiefgreifenden Kenntnisse hat. Außerdem sollten sich die Mitglieder aktiv an Communities beteiligen, die sich zu Scaled Agile austauschen..
SAFe ist unvollständig. SAFe ist nicht die einzige Sache auf der Welt. Schau darüber hinaus.
Es gibt viele Artikel in SAFe. Manche Leute werfen der Enzyklopädie sogar vor, dass sie so viel auflistet. Doch SAFe ist weit davon entfernt, vollständig zu sein. Und SAFe ist wirklich, wirklich nicht die einzige Quelle der Wahrheit. Wenn “Program Increments” nicht die richtige Wahl sind: Wähle LeSS-ähnliche Sprints. Passt das Unfix-Muster der flexiblen Teamzusammensetzung zu deiner Organisation? Warum solltest du dich nicht dafür entscheiden, wenn es die beste Option für deine aktuelle Situation zu sein scheint?
Siehe wie sich SAFe, Scrum@Scale, LeSS und unfix gegenseitig ergänzen.
Lassen wir einmal die unterschiedlichen Namenskonventionen in den Scaled Agile Modellen beiseite. Dann werden eine Menge Gemeinsamkeiten sichtbar. Das ist nicht überraschend. Die Werte und Prinzipien von Lean und Agile geben den Rahmen vor. Sie begrenzen damit die Möglichkeiten, um die Arbeit mehrerer Teams zu organisieren. Das bedeutet, dass die verschiedenen Scaled Agile Modelle nicht miteinander konkurrieren. Sie ergänzen sich vielmehr gegenseitig. Das ist ein Grund mehr, nicht zu schimpfen, sondern zu schauen, zu vergleichen und zu lernen.
Erfinde das Rad nicht neu.
SAFe und die anderen skalierten agilen Modelle haben einen großen Mehrwert. Sie bieten bewährte Lösungen (Muster) für typische Situationen. Damit müssen wir nicht das Rad neu erfinden. Das Adaptieren, Anpassen und Üben ist schon Aufwand genug. Wir sollten unsere Energie darauf verwenden. Die einzige Ausnahme wäre: Die Situation ist neu.
Bleib bei der bekannten Terminologie.
Die agile Terminologie ist schon verwirrend genug. Ein Beispiel gefällig? “Story” ist eine Größe, “User Story” ist eine Technik, und Jira verwendet den Begriff “Ticket”. Mach diese Verwirrung nicht noch größer. Verwende bekannte Begriffe, die es den Menschen in deinem Unternehmen ermöglichen nachzuschlagen. Die skalierten agilen Frameworks helfen dabei, sich an eine Terminologie zu halten. Entscheide dich für eines und halte dich daran. Klar ist das nicht optimal. Alle Modelle sind halt falsch.
Vergiss nicht die erste Regel der Skalierung: Skaliere nicht.
Die vielen schönen Muster sind noch lange kein Grund sie zu benutzen. Investiere bewusst in die erste Regel der Skalierung: Skaliere nicht. Das heißt: erst bewusst in Entkopplung investieren – und dann erst in die Organisation der Zusammenarbeit. In einer skalierten Umgebung ist alles exponentiell, auch Einsparungen durch Entkopplung. Statt einer “Large Solution” könnte man z. B. ein Portfolio mit entkoppelten ARTs nutzen. Statt eines Portfolio-Kanbans könnte man z. B. Objectives & Key Results (OKRs) nutzen. Wie immer bei Agilität: Verwende die einfachste Lösung, die den Zweck erfüllt.
Nimm die agile Transformation ernst.
Agil wird man nicht, indem man eine Enzyklopädie ausrollt. Eine skalierte agile Transformation dauert exponentiell länger als die Einführung von Agilität auf Teamebene. (Und wie lange habt ihr dafür gebraucht?) Die Pannen sind exponentiell größer. Der Schmerz ist exponentiell größer. Kleine Probleme auf Teamebene tauchen auf, wenn die Teams sich synchronisieren. Nehmt euch also Zeit und fügt der SAFe-Roadmap einen langfristigen Change Management-Ansatz hinzu. Die Artikel über Change Management in der SAFe Enzyklopädie sind ein guter Anfang. Aber auch hier gilt: Sie ersetzen nicht das Wissen über Change Management in der Tiefe. Change Management ist ein ganzes Wissensgebiet. Wendet es an.
Mehr zu Agiler Transformation
Mein Kollege Vincenzo Parisi hat einen guten Artikel geschrieben, wie man es mit SAFe vermasseln kann. Auf seine humoristische Art listet er die Dos als Don’ts auf. “Wie Du souverän Deine SAFe-Einführung vermasselst”. Eine klare Leseempfehlung von mir.
Über mich
Ich bin Malte. Ich habe viele Jahre Erfahrung mit agilen Methoden, Frameworks und organisatorischem Change Management. Ich habe eine Vergangenheit in der Produktentwicklung. Ich habe ein Beratungsunternehmen gegründet. Ich habe eines der ersten Bücher über die Skalierung von Agilität geschrieben (das seitdem jährlich aktualisiert wird). Wir führen agile Methoden in Teams und Organisationen ein. Wir wenden all diese Dinge bei uns selbst an. Und wir unterstützen viele Kunden. So, damit kennst du jetzt auch meinen bunten Hintergrund.
