Bei einem Kunden hat sich ein Sprichwort verselbständigt, dass Bände über die Schwierigkeit von SAFe-Einführungen spricht:
Better SAFe, then sorry.
Der Urheber soll unerkannt bleiben 😉
Wer jetzt schon den hämisch Rotstift auspackt, um zu markieren, dass es “than” heißen müsste, der:dem gebe ich gerne mehr Hintergrund. Denn dieses Sprichwort ist in jedem Wort wohl überlegt gewählt.
Am Anfang steht die grosse Frage im Raum, wie sich ein Unternehmen oder ein Unternehmensbereich zukünftig organisieren solle. Die schnelle Entscheidung zugunsten von SAFe entstehen oftmals aus dem Eindruck heraus, dass SAFe alles sei: umfangreicher, fundierter, anwendbarer, skalierbarer, übertragbarer als andere Rahmenwerke.
Und wie toll, dass das Akronym von SAFe gleich suggeriert, dass die ganze Sache super sicher sei. Was soll schon schief laufen?
In der Umsetzung zeigt sich dann allerdings, dass auf die grosse Begeisterung Ernüchterung folgt. Die ist bisweilen im SAFe-Kontext noch größer, weil SAFe so viele Empfehlungen gibt, so präskriptiv erscheint. Diese Ernüchterung ist, das werden wir am Ende sehen, ist weder einzigartig, noch besonders für SAFe-Einführungen.
Die blaue Theorie
SAFe -und das ist eine der Stärken des Rahmenwerkes- gibt viele Informationen mit. Das faszinierende ist, dass sich diese Informationen auf gute Praktiken und Untersuchungen von erfolgreichen Umsetzungen beziehen. Wer würde schon gegen die acht Schritte Kotters argumentieren? Zumal da oben rechts dieses Symbol mit den tollen Business Results lockt? Und auf den SAFe-Seiten einige Beispiele von Unternehmen sind, die SAFe nach eigenem Bekunden sehr erfolgreich eingeführt haben?
Nun, schauen wir erstmal, wie Scaled Agile eine Einführung vorschlägt. Es gibt mit “Go SAFe” eine klare Entscheidung für SAFe. Jetzt startet erst einmal Training mit den “Lean-Agile Change Agents”, den “Executives, Managers, and Leaders” allen, die für die Einführung von SAFe positive Effekte haben können. Ich verweise an dieser Stelle schon mal auf einen Fehler: Nur die “Manager” von heute trainieren.
Am Ende der ersten Gerade wird die Wertschöpfung evaluiert, sehr sinnvoll, wie ich selbst auch beschrieben habe.
Auf dem Weg zur zweiten Gerade wird der erste (und zunächst einzige) Agile Release Train vorbereitet.
In der Kurve zur dritten Gerade geht es dann im wesentlichen ums Wiederholen der positiven Erfahrungen der bisherigen Transformation.
So weit, so einfach. Aber das ist ja nur die blaue Theorie. Daher auf, auf zur bunten Praxis.
Wie Du mit Sicherheit souverän an Deiner SAFe-Einführung scheiterst.
Die folgenden Nicht-Empfehlungen sind ganz im Stile Watzlawicks “Anleitung zum Unglücklichsein” gehalten. Was Scheitern ist und was Erfolg, ist oftmals subjektiv, so wie dieser ganze Artikel. Seltener gibt es kollektiv objektivierte Metriken, die Erfolg oder Misserfolg präzise definieren.
Ich adressiere nicht einzelne Personen, und nicht einzelne Unternehmen. Und, zugute haltend: Dort, wo wir Entgleisungen der ARTs erleben konnten, war es erstens niemandes Absicht und zweitens danach stets mit gemeinsamen Engagement auf gutem Wege. Denn im Grunde sind die Menschen gut.
Ich hoffe daher, Du findest stets den richtigen Pfad innerhalb der nun folgenden Ironie und weisst die folgenden Zeilen klug umzudenken.
Entscheide Dich für die eine Art der SAFe-Einführung
Es gibt nur zwei Möglichkeiten der SAFe-Einführung.
- Variante Eins: Alles genau nach der vermeintlichen Theorie machen (da ist ja super viel beschrieben!). Das bedeutet auf keinen Fall abzuweichen von den Beschreibungen. Dort wo Interpretation erforderlich ist (es ist ja doch nur ein “framework” und kein “manual”) einfach im Sinne des Erfinders (Dean dankt Dir) interpretieren. Wichtig ist, in diesem Falle darauf zu bestehen, dass es nur diese eine Wahrheit gibt. Sonst wird das ganze Unterfangen irgendwann kontrafaktisch.
- Variante Zwei: SAFe als Empfehlung verstehen, aus der einzelne Elemente nach Bedarf kopiert werden können. Besonders hilfreich ist es für die Veränderung, wenn dabei auch die Begriffe angepasst werden. Wozu die ganzen bekannten Begriffe behalten? Das wäre unnötig kompliziert!
Tu so, als ob die Vergangenheit einfach nur Schrott gewesen wäre.
Es ist wichtig, allen klar zu machen, dass das bisherige Arbeiten schlichtweg ein unprofessionelles, kopfloses, selbstsüchtiges Arbeiten war. Am besten wird dafür eine Beratung engagiert, die zunächst Interviews führt, sich dann mit dem “Top-Management” einschliesst, um nach langen Tagen (und hohen Rechnungen) zu verkünden, das Alles anders werden müsse, es aber glücklicherweise nun einen Plan dafür gäbe.
Formuliere keinesfalls einen Grund für die Veränderung.
Auf keinen Fall darf ein Grund für die Veränderung formuliert werden. Dazu müssten sich alle Verantwortlichen viel zu sehr festlegen. Die Gründe für die SAFe-Einführung sind so vielfältig, es ist eine komplexe Situation und immer sowieso alles immer subjektiv. In der allergrössten Not kann die Beratung ein paar Powerpoint-Folien basteln, sicher gibt’s noch was vom vorherigen Kunden, das passt schon. Die Folien sollten im Intranet veröffentlicht werden, nicht ohne zuvor die richtige Sub-Sub-Seite dafür anzulegen. So haben schliesslich alle Zugang.
Die Argumentation sollte kompliziert aber offen sein, sie muss schliesslich der Situation gerecht werden. Keinesfalls dürfen einzelne Ursachen ausgemacht werden und es sollten keine auch keine abgefahrenen Zukunftsbilder gemalt werden. Nicht zuletzt ist eine für eine geordnete Transformation dramatische Dringlichkeit gänzlich unpassend.
Lass die Experten ran. Und nur die!
Entscheidend für ein souveränes Scheitern ist, dass echte Experten beteiligt sind. Von Leuten, die niedere Arbeiten, wie Programmierungen oder Tests durchführen, ist Abstand zu nehmen. Die sind viel zu tief in ihrem Klein-Klein und für solche grossen Ambitionen nicht zu gebrauchen.
Bringe ein paar Leute zusammen, nenne es LACE.
Glückwunsch, Du hast die Idee der Guiding Coalition (siehe Kotters acht Schritte weiter oben) verstanden. Jetzt geht es darum sie umzusetzen. Und was eignet sich besser, als die oben genannten Experten nun zusammen zu bringen? Scaled Agile schlägt dafür das Lean-Agile Center of Excellence, kurz LACE, vor. Es ist gewissermassen die Schnüre um die ganze SAFe-Einführung!
Solch hochkarätige Mitglieder haben natürlich vielerlei Verantwortung, daher können sie in einem LACE nur zu 20 oder 50 oder so Prozent mitwirken. Damit es glaubwürdig ist, muss es aber dennoch Team heissen.
Zwar ist in SAFe alles mit agilen Methoden organisiert, aber unter Profis kann das auch mal beiseite gelassen werden. Die wissen schon, was sie machen. Daher benötigen sie auch keinen Scrum Master (Scrum) oder Service Delivery Manager (Kanban).
Es ist leicht vorstellbar, dass die Oberchef:innen (selten habe ich ein so schönes Wort „gegendert“) auch keine Zeit haben. Daher ist es höchst unwahrscheinlich, dass sie im LACE-Team mitarbeiten. Keinesfalls sollten sich ein:e Oberchef:in in der Rolle eines Product Owners (Scrum) oder Service Request Managers (Kanban) einsetzen, denn damit wären sie viel zu nah dran. Regelmäßige sorgfältig aufbereitete Statusreports sind stattdessen das Mittel der Wahl für die Abstimmung mit dem LACE.
Da SAFe eine so wunderbare, umfassende Website hat, sind Trainings (gar SPC-Ausbildungen) für Einzelne oder gar Alle im Team nicht notwendig. Wissensarbeitende wissen schliesslich, wie sie sich die SAFe-Expertise erarbeiten, ist ja alles da.
Jetzt geht’s endlich richtig los!
Genug der Pläne, die müssen umgesetzt werden! Daher sollten möglichst schnell, möglichst viele Teams entstehen und ARTs “gelauncht” werden. Ach was, gleich noch mindestens eine Large Solution und am besten noch das Portfolio hinterher. Ein zuverlässiges Mittel um alles zu vermasseln ist alles gleichzeitig, mindestens aber ganz schnell zu “launchen”.
Wer sich die Mühe macht, Scaled Agile in den Tiefen der Dokumente zu durchforsten, stösst auf die obige Folie. Mit ein bisschen Fantasie kann sie so ausgelegt werden, dass eine der vier Mengen immer zutrifft: Mal ehrlich, eine grosse Herausforderung gibt’s doch immer? Siehst du, dann ab mit diesem Haufen Leute auf die Abschussrampe zum „Launch“!
Zum „Erfolg“ verhilft daher auch, die Zahl von Teams und ARTs als Erfolgskriterium zu messen: Je mehr, desto mehr. Das Vorgehen ist selbst dann hilfreich, wenn später die Zahl der Menschen in einem Team grösser wird: Einfach ein neues Team gründen!
Zu viele Teams für einen ART?
Einfach einen neuen ART gründen!
Und zu viele ARTs?
Eine Large Solution!
Was, nicht alles passt in die Large Solution?
Gründe eine Super Large Solution. Die ist dann auch beliebig skalierbar und das Problem wird einfach wegskaliert.
Ich habe auch schon mehrere Portfolio (Portfolieusen?!) gesehen, die ineinander verschachtelt waren, das ist dann was für echte Kenner:innen.
Rollen, Events und Artefakte sind…nett.
SAFe ist eine dual organization. Das ist auf den ersten Blick oftmals nicht klar und sorgt später für Verwirrung. Böse Zungen behaupten, diese Dual Organization sei da, um Verwirrung zu stiften. Dabei ist es eigentlich ganz einfach: Rechts ist das alte, bekannte. Links ist das neue Dings. Es gilt nun kreative Verbindungen zu schaffen, ähnlich wie bei den zwei Arten der SAFe-Einführung.
Ich zeige sicherheitshalber ein Beispiel, das mit dem Ziel des Vermasselns nicht befolgt werden sollte:
Die finnische Nordic Bank hat Entwicklungspfade für die Menschen in ihrer Linienorganisation aufgezeigt. Aber das nimmt nur Flexibilität und damit ja Agilität. Um die soll’s doch eigentlich bei dem Ganzen gehen! Kann also nix sein.
Stattdessen empfiehlt es sich, mit fluiden Rollen zu hantieren. Das heißt, mehreren Personen eine Rolle zuweisen und so besonders gut das heutige Bild der Organisation in die Zukunft transportieren. So ähnlich muss sich das Kotter in seinem Buch Accelerate gedacht haben. Ernsthaft. Hust.
Keine Trainings für niemanden!
Überhaupt sind Trainings für Dummies, die sich eine Woche lang berieseln lassen wollen und abends in der Hotelbar abhängen. Lass Dich nicht von Prüfungen und Zertifikaten täuschen! Das gilt sowohl fürs LACE, wie auch für alle anderen. Klar, SAFe ist umfangreich. Aber Deine Mitarbeitenden sind doch nicht blöd? Die lernen doch eh ihr Leben lang. Die Trainings und Zertifizierungen kosten unglaublich viel Geld.
Kommunikation ist super wichtig!
Change ist zum großen Teil Kommunikation. Das ist das 1×1 des Change, wird rauf und runter gebetet und alle nicken anerkennend. Wer dilettantisch scheitern will, versucht Ergebnisse zu schaffen und darüber zu reden. Wer grandios scheitern will, muss reden und dann Ergebnisse schaffen. Es hilft Kommunikationexperten (s.o.) dabei zu haben, die alles aber wirklich alles so vergolden können, dass gestandene Alchemist:innen vor Neid erblassten.
Zum nicht Scheitern, sei ein gänzlich alternativer Ansatz empfohlen: walk the talk. Aber das wäre langweilig.
Architektur kommt von allein
Wenn dann mal das Vorgehen agil ist, kann die ganze Entwicklung gar nicht mehr anders, als in einer agilen Architektur und leistungsfähigen Lieferorganisation (Fachbegriff: Continuous Delivery Pipeline) zu münden! Weiss auch nicht jeder. Viele meinen ja, da müsste aufwändig gestaltet werden. Manche behaupten sogar, ohne die entsprechende Geschäfts- und technische Architektur wäre agiles Arbeiten gar nicht nötig. Aber das sind meist so Einzelgänger, die nur wieder neues Spielzeug wollen, nie an den Kunden (sic!) denken und einfach nichts fertig kriegen.
Last but not least: SAFe. Muss. Sein.
Einer der wichtigsten Faktoren kommt zum Schluss, die Kirsche auf dem Sahnehäubchen des Schokoladeneises. SAFe sollte trotz alle Risiken und Nebenwirkungen eingeführt werden. Weil es die anderen auch machen und es demzufolge gut ist. Das wird auch die Zukunft zeigen:
Nicht skalieren.
Ich kann nicht nicht. Ich werde kurz vor Ende doch schwach und gebe einen ernst gemeinten Rat – vor der Einführung von skalierte Agilität: Tu’s nicht. Hier schreibe ich mehr zum nullten Prinzip der Skalierung.
Und jetzt Du! Was trägt noch zum erfolgreichen Scheitern bei?
Natürlich gibt’s noch viel mehr Gründe für SAFe-Einführungen, die nicht die vorher gesetzten, kommunizierten Ziele erreichen – oder die Lieferfähigkeit nicht tatsächlich verbessern – oder zu großer Unzufriedenheit unter den Mitarbeitenden führen. Obwohl es hier SAFe-spezifisch ist, erkennen die fachlich verdorbenen Leser:innen, dass Vieles für persönliche und organisationale Veränderungen typisch ist. Und letztendlich ist eine SAFe-Einführung eine organisationale Veränderung. Daher sind die eingangs erwähnten Ernüchterungen weder einzigartig für bestimmte Unternehmen, noch besonders für SAFe.
Aber irgendwann muss auch an diesen Artikel ein Schlusspunkt. Denn es gibt auch Faktoren, die zu einer positiven Einführung beitragen. Falls das von Interesse ist, gib Bescheid, dann setze ich mich mal an einen Artikel. So lange gilt auf jeden Fall, dass das Vermeiden der gröbsten Fehler schon einen wesentlichen Teil zum Erfolg beiträgt.
Alternativ kann ein Fragezeichen ans Ende des Artikels. Also denn: Was ist Dir noch begegnet (natürlich nur bei anderen), dass Du hier teilen kannst?
