SAFe und die Good Practice von Inspect & Adapt

Um es von Anfang an klar zu stellen: Ich bin weder ein SAFe Jünger, noch gehöre ich der SAFe verteufelnden Gemeinde an. SAFe ist für mich ein pfiffig zusammengestelltes Framework an Methoden und good practices. Und genau hier ist der Punkt: SAFe ist ein Framework aufgebaut aus agilen Methoden und good practices.

Das bedeutet für mich persönlich: Wenn sich eine Organisation entscheidet SAFe einzusetzen, so analysieren wir zuerst den Kontext des Einsatzzweckes und identifizieren den Veränderungsbedarf, der in dem Kontext den höchsten Wert liefert. Das “wir” ist das Transformationsteam, das aus internen und externen Mitarbeitenden besteht.

Haben wir diesen Veränderungsbedarf identifiziert, so sehen wir in das SAFe Framework und nehmen die erste Kombination an Methoden und good practices heraus, welche diesen Bedarf adressieren. Das sind vielleicht nur vier oder fünf Dinge, vielleicht auch zwanzig. Das ist ein erstes Set an Methoden, Rollen, good Practices – was auch immer. In einem Inspect & Adapt Verfahren adaptieren wir dieses Set an die Spezifika der Organisation. Parallel dazu erarbeiten sich alle in die Transformation eingebundenen Mitarbeitenden mit begleitenden Training und Coaching Massnahmen die Anwendung der Methoden und good Practices, was wiederum eine reichhaltige Quelle für Feedback ist. Eigentlich ist das ja nicht Neues. Das ist ein agiles Vorgehen. SAFe selbst schlägt vor so zu arbeiten.

So bringen wir in kurzer Zeit ein optimiertes “Operating Model” operativ zum Einsatz. Oder in “agiler” Nomenklatur formuliert: So verankern wir das nächste MVP auf der Reise der kontinuierlichen Optimierung in der Organisation. Jedes MVP deckt das nächste Set an Bedürfnisse der agilen Organisation ab. So optimieren wir Schritt für Schritt, wenn Veränderungsbedarf besteht.

SAFe als Framework, nicht als Rezept einsetzen

Wenn wir in dieser Art und Weise eine Transformation angehen, dann ist es sehr wahrscheinlich, dass nicht alle Elemente aus dem SAFe Framework zum Einsatz kommen – unabhängig davon welche SAFe Konfiguration als Ausgangspunkt genommen wurde. Es ist ebenfalls sehr wahrscheinlich, dass einige Elemente des SAFe Framework an die Spezifika des Unternehmens angepasst werden. Gründe dafür sind vielfach vorhanden. Ich liste ein paar ausgewählte Grunde exemplarisch auf:

• Ein gut verstandenes und brauchbares Verfahren wie Business Value in der WSJF Formel geschätzt wird ist bereits etabliert und kann auch weiterhin genommen werden, es weicht jedoch vom SAFe Verfahren ab.
• Es gibt bereits einen etablierten sechs Wochen Rhythmus, in dem eine Synchronisierung auf Team of Teams Ebene stattfindet mit definierten Events. Dies weicht vom typischen PI ab.
• Das Unternehmen hat bereits OKR im Einsatz und nimmt diese für eine Solution anstatt PI Objectives.
• Das Unternehmen agiert in zwei Geschäftsfeldern, die fachlich und systemtechnisch komplett disjunkt sind und entscheidet sich für zwei disjunkte Portfolios, welche über einen von SAFe abweichenden Portfolio Mechanismus abgestimmt sind.
• Das Unternehmen arbeitet intensiv mit externen Zulieferern zusammen, die zum grossen Teil noch nicht agil arbeiten – warum auch immer.
• Ein grosser Anteil der Projekte im Unternehmen ist nur bedingt agil, da gesetzliche Regelungen oder organisatorische Rahmenbedingungen feste Termine, finanzielle Rahmenbedingungen oder andere Rahmenbedingungen mit sich bringen. Die Tatsache fester Termine benötigt eine Anpassung der rein Wert orientierten Priorisierung (d.h. selektive bindende Termine haben einen bindend hohen Wert).

Was ich persönlich beobachte, ist eine gewisse Starrheit in der Einführung von SAFe. SAFe wird als Rezept angewendet und nicht als Framework. Ich sehe dies nicht im Framework selbst begründet, eher an der Art und Weise wie SAFe in vielen Fällen eingeführt wird – nämlich nicht agil Schritt für Schritt; nicht in einer Inspect & Adapt Art und Weise; nicht in der Art im Unternehmen bereits etablierte bewährte good practices zu integrierten oder SAFe Framework Elemente durch diese zu ersetzen. Dabei ist SAFe selbst auf diese Weise entstanden, indem bewährte Kombinationen von Methoden und good practices aus real life cases in einem übergreifenden Framework vereint wurden. Ich persönlich stelle vielfach eine stark dogmatische Haltung in der Einführung von SAFe fest. Schade, denn ein wichtiger agiler Wert geht hier verloren.

Wiederholt sich die Geschichte?

Ich weiss nicht ob sich die werten Leser dieses Blog sich noch an den Rational Unified Process erinnern. Ivar Jacobson, Grady Booch und James Rumbaugh als Innovatoren kreierten zuerst den Modellierungsansatz UML und darauf aufsetzend RUP als ein leichtgewichtiges iteratives Process Framework. Auch, wenn viele nun laut auflachen – das war damals der Grundgedanke von RUP. Im Laufe der Zeit wurde RUP (leider) von IBM übernommen (ich hätte beinahe gekapert geschrieben), um immer mehr Elemente erweitert, bis nach zirka 10 Jahren ein gewaltiges und viel zu kompliziertes Framework auf dem Markt war. RUP war sehr populär. Es war das erste iterative Framework, der Bruch mit “Wasserfall”. In der Einführung von RUP verpassten jedoch viele Unternehmen und noch viel mehr der “Rezept” Consultants, welche RUP Einführungen als Experten begleiteten, den Schritt des Tailorings, also die Anpassung des Framework an das Unternehmen. Das Wichtigste im Tailoring war Elemente herauszustreichen, die nicht benötigt werden. Die Folge waren schwergewichtige RUP Implementierungen. Das RUP Framework kam in den Ruf kompliziert und aufwendig zu sein, ein bürokratischer Wahnsinn, welcher die Organisation überlastet. Dabei war nicht das Framework der Fehler, sondern das mangelhafte Tailoring, das heutezutage als Inspect & Adapt durchgeführt wird.

Diese schadhafte Entwicklung von RUP war unter anderem die Geburt und Chance für leichtgewichtige Ansätze wie Scrum, Kanban, die schliesslich zu SAFe oder LeSS führten, auch zu (vergeblichen) Versuchen RUP am Leben zu halten als “Essential Unified Process”. An der Stelle sei mir eine Frage gestattet: Wiederholt sich nun mit SAFe eine Entwicklung, wie sie RUP durchlaufen hat?

Mich persönlich interessiert die Antwort übrigens nicht. Mich persönlich motiviert es zusammen mit den Mitarbeitenden im Unternehmen zu arbeiten, so dass ihr Unternehmen in der Lage ist seine Vision zu verwirklichen; zusammen das für die Organisation und das Ökosystem beste “Operating Model” designen, das schlank und adaptierbar ist, in dem es Freude bereitet etwas Wertvolles zu bauen. SAFe, LeSS, Spotify, … sind fantastische und inspirierende Quellen für den Start und das notwendige Inspect & Adapt.

Um es ganz deutlich zu sagen: Mit Freude wertvolle Produkte und Services für Kunden zu bauen ist das Ziel. Ein geeignetes Operating Model ist Mittel zu Zweck. Das Operating Model ist – und hier finde ich keine passende Übersetzung ins Deutsche “not an end in itself”.