SAFe finden wir scheinbar in jeder hochskalierten agil (oder scheinbar agil) ausgerichteten Entwicklung. Der Grund dafür ist einfach: es liefert Antworten für die Fragen hochkomplexer Projektumgebungen. Genau dafür wurde es entwickelt. Doch überall und immer wieder hören wir auch lautstarke Kritik an dieser populären Scrum Skalierung. Ist diese Kritik berechtigt?
Wer in seiner eigenen Organisation innerhalb von SAFe arbeitet, kennt die damit verbundenen Schmerzen. Wer Google fragt, wird schnell Kritikpunkte an SAFe finden, und auch ich bin nicht der größte Fan, obwohl ich seit über zehn Jahren in unterschiedlichen Projekten und in unterschiedlichen Rollen damit arbeite. Warum ich jedoch nicht der größte Fan bin, unterscheidet sich von den am häufigsten genannten Kritikpunkten. Auf diese möchte ich im Einzelnen schauen und meine Sicht schildern, ob sie berechtigt ist, und ob wir Alternativen haben.
Zu viel Bürokratie und zu hohe Komplexität
Woher dieser Vorwurf kommt, ist leicht zu verstehen. Wenn man zum ersten Mal das Big Picture sieht, stellt sich zunächst ein Schwindelgefühl ein, gefolgt von leichtem Brechreiz, haben wir doch gelernt, dass der Schlüssel zum Erfolgt in der Vereinfachung liegt. Wir finden scheinbar endlos viele Rollen und Gremien, Artefakte und Prozesse.
Der erste Impuls ist: so viel braucht kein Mensch – das ist völlig überzogen. Dem setze ich entgegen, dass SAFe nur dann Sinn hat, wenn wir über eine hochkomplexe Entwicklung und eine Skalierung über sehr viele Teams sprechen. Bei vier Entwicklungsteams bin ich auch bei LeSS, aber SAFe wurde entwickelt für eine Skalierung über zwanzig oder fünfzig Teams, und dann funktionieren diese sehr einfachen Systeme einfach nicht mehr.
Die gemeinsame Arbeit über 25 Teams an einem Produkt zu koordinieren, ist eine Mammutaufgabe, und sie ist in keiner Weise trivial. Wir haben endlos viele Abhängigkeiten untereinander, und keine einzelne Person kann alles im Blick haben und alles in größter Tiefe durchdringen und verstehen. Um mit diesem Grundproblem umzugehen, gibt es zwei mögliche Ansätze, einen Basisdemokratischen mit einer extrem flachen Struktur und einen kaskadierenden über mehrere Skalierungsebenen.
Auch wenn ich ein großer Freund der Demokratie an sich bin, in diesem Fall würde sie sich selbst komplett zerfleischen. Wir hätten dann 25 Teams (und hier wären wir noch bei einer kleinen SAFe Skalierung), die an einem Tisch säßen und alles untereinander ohne Steuerung miteinander koordinieren müssten. Könnt Ihr Euch vorstellen, wie gut das funktionieren wird?
Diese übereinander gestapelten Skalierungs- und Entscheidungsebenen Team, Train und Solution bringen zwangsläufig mehrere Rollen mit sich, zwangsläufig gibt es mehrere Ebenen von Artefakten, und zwangsläufig gibt es auch mehrere Ebenen von Abstimmungen.
Schauen wir auf jede Ebene, sind das gar nicht so viele Rollen. Wir finden immer die heilige Dreieinigkeit von Technik, Fachlichkeit und Prozess – auf jeder Ebene. Entwickler, PO und SM im Team, Architekt, PM und RTE im ART. Jede Ebene hat vergleichbare Artefakte, die aufgeteilt werden, wenn sie an die nächstgelegene kleinere Skalierung übergeben werden. Das Grundprinzip ist vollkommen logisch.
Es ist auch logisch, dass es ab dem ART eine Businesskomponente gibt – dort in Form der sogenannten Business Owner. Diese sollen sicherstellen, dass wir uns auf die wichtigen Dinge konzentrieren, weil es eben nicht möglich ist, dass alle Personen alles überblicken.
Die entscheidende Frage ist für mich damit nicht, ob SAFe hochkomplex ist – das ist es, sondern ob jede erzeugte Komplexität über Rollen, Artefakte, Gremien auch einen Nutzen liefert. Meine Antwort darauf lautet: in der Theorie ja (zumindest meistens – wir können hier jedoch nicht auf jedes kleine Detail eingehen, nicht alles ist perfekt). Die Schwäche ist eher die praktische Umsetzung.
Ich habe mit der Grundaufstellung von SAFe keine Probleme. Meine persönliche Kritik zur hohen Komplexität liegt im Detail und in einigen Rollen, in denen ich zu große Redundanzen sehe. Das sind beispielsweise RTEs/STEs, LACE Team, SPC, ASPC und VMO.
Ich weiß, formal sind die irgendwie getrennt, aber eigentlich auch nicht, weil es in der Praxis große Überschneidungen gibt, und die meisten Entscheider, die letztlich die Budgets freigeben, fragen: »Habt ihr noch alle Latten am Zaun? Wie viele Rollen sollen wir denn noch finanzieren, die alle dasselbe tun?« Meistens landen dann alle Aufgaben bei den RTEs und STEs, die man sowieso hat, und – ganz offen – kann ich damit wunderbar leben.
Wasserfall im Agile-Kleidchen
SAFe plant weit im Voraus – das ist richtig. Wir schauen nicht nur auf ein PI von oftmals zehn Wochen. Wir schauen weit darüber hinaus. Wir haben Projektpläne, wir haben Roadmaps, wir haben nicht selten Jahresziele.
Ist das ein Problem? Oder ist es nicht anders möglich? Ich meine, dass wir bei einer so hohen Komplexität keine andere Wahl haben, als auch längerfristig zu schauen. Die Frage ist vielmehr, wie wir das tun, wie wir zu unseren Entscheidungen kommen und wie beweglich wir bleiben.
Eines muss uns bewusst werden: je komplexer ein Projekt ist, desto größer werden zwangsläufig die Planungsiterationen, weil wir eine sprintweise Planung nicht leisten könnten. Es greift wieder das Prinzip der Kaskade. Größere Ziele mit großem Planungshorizont werden aufgebrochen in kleinere Ziele mit kleinerem Planungshorizont. Das läuft nicht zwangsweise dem agilen Prinzip von kontinuierlichem Lernen aus Erfahrungen und einer damit verbundenen kontinuierlichen Anpassung des Plans entgegen. Die Anpassung des Plans geschieht nur auf mehreren Ebenen, die unterschiedliche Zeithorizonte erfordern.
Solange wir das tatsächlich tun, ist das vollkommen in Ordnung. Wenn wir im Kleinen wie im Großen auf Veränderungen und Erkenntnisse reagieren und unsere Pläne entsprechend anpassen, ist das OK. Wir verlassen lediglich das Agile Spielfeld, wenn wir einen einmal gefassten Plan in Stein meißeln und ihn durchdrücken wollen, anstatt ihn anzupassen.
Ich verstehe diesen Kritikpunkt sehr gut, weil das genau die Tendenz ist, die wir häufig sehen. Das Problem ist damit aber nicht das SAFe-Framework sondern dessen Umsetzung. Auch der Zeitrahmen eines PIs von ganz grob einem Quartal, ist eine lange Zeit. Teams sind nicht in der Lage, ein Vierteljahr zu 100% durchzuplanen. Es werden sich Veränderungen ergeben, und wir müssen beweglich genug bleiben, darauf zu reagieren.
Sehr starke Top-Down Steuerung
Wir legen viel Wert auf Selbstorganisation. Das ist vollkommen richtig, und ich stehe voll und ganz hinter dem Prinzip, dass Entscheidungen gefälligst dort getroffen werden, wo das größte Wissen liegt. Wir laufen jedoch wieder in das Problem der hohen Komplexität.
Wir nehmen den Teams die Entscheidungsfreiheit über die Fachlichkeit, weil wir die Fachlichkeit über viele Teams miteinander koordinieren müssen. Die Solution entscheidet über Funktionalitätsbündel, die von mehreren Trains umgesetzt werden. Der Train entscheidet über einzelne Funktionen, die von mehreren Teams umgesetzt werden. Für das einzelne Team bleibt da nicht viel Entscheidung übrig.
Auch die technische Umsetzung geht durch die Architekten zu den Teams, weil wir auch das miteinander koordinieren müssen. Ebenso verhält es sich mit Prozessen und Arbeitsweisen, weil auch diese über viele Teams zueinander passen müssen.
Die Frage ist nicht, ob die Teams stark fremdgesteuert sind – das sind sie, sondern wie weit wir gehen müssen und welchen Ansatz wir nehmen. So viel wie möglich zentral steuern und das lokal entscheiden lassen, was nicht anders geht, oder andersrum. Natürlich bin ich ein Freund von so viel Freiheit wie möglich in den Teams zu belassen und nur der Notwendigkeit folgend Entscheidungen auf die nächst höher gelegene Skalierung heben.
Das Problem ist meiner Meinung nach auch hier nicht das System als solches, sondern erneut die konkrete Umsetzung, die sehr oft dem Managementprinzip der zentralisierten Steuerung folgt und gar nicht erst versucht, Entscheidungen in die Teams zu verlagern.
Die Schwäche von SAFe ist, dass es dazu verleitet und es sehr einfach macht.
Hoher Einführungsaufwand
Ja. Keine Frage. Eine SAFe-Implementierung dauert viele Monate, und die Schmerzen daraus können sogar Jahre anhalten. Damit unterscheidet es sich in keinster Weise von jeder anderen Reorganisation.
Wir sprechen hier von nichts anderem. Die Einführung von SAFe ist eine Reorganisation – neue Rollen und neue Prozesse. Es liegt in der Natur der Sache, nämlich wieder in der hohen Komplexität und in der damit verbundenen großen Skalierung, dass alles so lange dauert und so aufwändig ist. Jede Reorganisation in dieser Größenordnung erzeugt dieselben Aufwände.
Die Frage nach dem Aufwand an sich reicht nicht aus. Viel wichtiger ist die Frage, ob der Aufwand zu dem, was ich mir davon verspreche, in einem vernünftigen Verhältnis steht. Und dann haben wir noch nicht darüber gesprochen, ob das, was ich mir davon verspreche, überhaupt eintritt.
Es gibt viele mögliche Motivationen für die Einführung von SAFe. Einige sind sicherlich realistischer als andere, und die Bewertung, ob die Lösung Eures Problems mit SAFe erreichbar ist, kann sehr schwierig sein, diese Entscheidung wird aber auch nicht leichtfertig getroffen. Das einzige, was ich hier sagen kann, ist, dass ich leider schon einige Unternehmen und Berater getroffen haben, die sehr vollmundige Versprechungen gemacht haben. Man müsse nur ein paar Schulungen machen, ein paar Rollen anders nennen, ein paar Prozesse ändern. Die Sache wäre innerhalb weniger Wochen erledigt, und dann würden sich unfassbare Performancegewinne einstellen, aber ohne zehn Zertifikate und zwanzig Berater geht nix.
Nein. Einfach Nein. So einfach ist es nicht. Wir müssen viel ändern. Diese Änderungen gehen tief. Viele Personen müssen viele Dinge lernen, und die haben sie nicht komplett drauf nach einer kurzen Schulung. Die Schulungen sind immer nur initial, das wahre Lernen folgt in der praktischen Arbeit.
Und Performance können wir auch nur indirekt gewinnen, indem wir die Prozesse um die eigentliche Leistungserbringung in den Teams herum besser machen.
Über den ganzen Zertifizierungswahnsinn möchte ich nicht einmal sprechen. Das ist ein Thema für sich und betrifft nicht nur SAFe. Ich bin der Meinung, dass man auch ohne eine ganze Tapete aus Zertifikaten einer Organisation ganz prächtig helfen kann. Letztlich ist jedes Zertifikat nur graue Theorie.
Meine persönliche Kritik an SAFe ist, dass ich einige Rollen für redundant halte, was aber das kleinere Problem ist. Mein größerer Kritikpunkt ist, dass es eigentlich zu wenige Vorgaben macht. Damit verleitet es sehr stark dazu, in alten Denkweisen zu verharren, an der Zentralisierung festzuhalten, anstatt eine Dezentralisierung zu fördern, soweit das möglich ist, und altes starres Planungsverhalten beizubehalten, anstatt zu einer kontinuierlichen Anpassung des Planz gezwungen zu werden, weil es den Rückkanal Bottom-Up – die Erkenntnisse aus den Teams – nicht standardisiert und damit zu stark dazu verleitet, diesen zu ignorieren.
Wenn Ihr diese beiden Probleme selber in den Griff bekommt, abseits der Vorgaben (oder fehlenden Vorgaben) aus dem SAFe Framework selbst, dann seid Ihr gut unterwegs. Und dann stellt sich eigentlich auch nicht mehr die Frage, ob Ihr agil seid oder nicht.
Wenn Ihr mehr erfahren wollt, oder Unterstützung braucht, sprecht mich einfach an.
