Digitalisierung und Disruption

SAFe – agile Schatztruhe oder Ballast?

Dieser Beitrag wurde ursprünglich von Johannes Kling zur SAFe-Version 4.0 geschrieben. Seitdem wurde SAFe weiterentwickelt und einiges an der damals geäußerter Kritik berücksichtigt. Entsprechend wurde der Beitrag überarbeitet, um auf den letzten Entwicklungsstand einzugehen, zuletzt von Romano Roth und Johannes Kling gemeinsam.
 

7 Minuten Lesezeit
Mit Insights von

  • SAFe ist umstritten, aber viel besser als sein Ruf.

  • SAFe ist teils kompliziert und restriktiv, bietet aber auch einen umfangreichen Fundus wirksamer Praktiken.

  • SAFe dient nicht als Blaupause, sondern eher noch als geeigneter Zwischenschritt in Unternehmen, die an ihrer Agilität arbeiten. 

  • Unternehmen, die das Framework als Werkzeug(-kasten) nutzen und organisatorisch flexibel bleiben, können von SAFe profitieren.

Swisscom, BMW, die Deutsche Bahn, TomTom und viele weitere Unternehmen setzen das Scaled Agile Framework (SAFe®) ein. Die Nachfrage nach Weiterbildung und Beratung zur Skalierung von Agilität ist groß. Doch nicht alle Erwartungen an das Framework erfüllen sich.

Dieser Beitrag wurde ursprünglich von Johannes Kling zur SAFe-Version 4.0 geschrieben. Seitdem wurde SAFe weiterentwickelt und einiges an der damals geäußerter Kritik berücksichtigt. Entsprechend wurde der Beitrag überarbeitet, um auf den letzten Entwicklungsstand einzugehen, zuletzt von Romano Roth und Johannes Kling gemeinsam.
 

Beide kennen SAFe und die entsprechenden Kurse des Scaled Agile Institute (SAI) aus mehreren Blickwinkeln: anfänglich waren sie Teilnehmer von Kursen wie Leading SAFe oder Implementing SAFe; sie helfen Unternehmen bei der Einführung agiler Methoden (von denen sich einige zumindest an SAFe orientierten) und geben Trainings zu Agilität, unter anderem zu SAFe.

Wir beide, Romano und Johannes, erinnern uns noch gut: Anfänglich hatten wir große Vorbehalte gegenüber SAFe. Das damalige Modell erschien uns unnötig kompliziert und schwer vermittelbar, inhaltlich unzureichend und einiges damals widersprach grundsätzlich unserem Verständnis der agilen Prinzipien. Kurz: Uns erschien SAFe wie methodischer Ballast. Eine Einschätzung, die einige laute Stimmen in der Community äußern.

Zugegeben, eine kritische Grundhaltung zu SAFe und der SAI haben wir beide uns bewahrt. Inzwischen sehen wir SAFe aber nicht mehr als Ballast, sondern in erster Linie als eine Schatztruhe erprobter Muster (in der Agilität, Lean Production, Lean Startup, aber auch traditioneller Vorgehensweisen wie dem RUP), die in einen logischen Zusammenhang geordnet sind.

Ist SAFe über Kritik erhaben? Sicher nicht. Auf einige Punkte möchten wir besonders eingehen und unsere Einschätzung gegenüberstellen:

"Unser Unternehmen wird mit SAFe nicht besser (profitabler, kundenorientierter, innovativer, … )."

Lange war SAFe in erster Linie ein Framework zur Produktentwicklung mit lean-agilen Methoden. Wenn in SAFe-Versionen vor 5.0 von "Value Streams" die Rede war, waren fast immer "Development Value Streams" gemeint - nicht betriebliche Wertschöpfungsketten (Operational Value Streams), die den Geschäftswert (Business Value) direkt beeinflussen. 
Bei der Begeisterung für vermeintlich einfache Lösungen (wie beispielsweise eine "Agile Transformation") konnte dieser Umstand leicht ignoriert und falsche Erwartungen geweckt werden. 

  • Einem Technikproduzenten ohne Idee, wie er mit Wettbewerbern in der Digitalisierung umgeht, kann eine agile Entwicklung nur helfen, wenn er auch Mut zur Innovation beweist.
  • Eine Bank braucht mehr als nur skalierte Agilität, um die Kundenorientierung ihrer Betriebsorganisation zu stärken und ihre Angebote attraktiver zu machen.
  • Eine Behörde, die ihre Attraktivität als Arbeitgeber am Markt verbessern will, muss nicht „Essential SAFe“ einführen, sondern sich systemisch ändern, um der intrinsischen Motivation der Mitarbeitenden Raum zu geben und sie zu nutzen.

Mit Version 5.0 hat SAFe diese Punkte aufgenommen und sein Modell beträchtlich erweitert. Seitdem macht SAFe (in den Konfigurationen „Portfolio“ und „Full“) das Streben nach Business Agility zum Fokus. Es setzt zum Beispiel zusätzliche Schwerpunkte auf Organisatorische Agilität und eine Kontinuierliche Lernkultur. Entsprechend hat es weitere Methoden integriert, wie die Analyse betrieblicher Wertschöpfungsketten oder Objectives and Key Results (OKR) und Elemente aus Eric Ries‘ „Lean Startup“ und das Business Model Canvas von Alexander Osterwalder / Strategyzer adaptiert. SAFe legt – für das ganze Unternehmen – auf die Lernende Organisation, Innovationskultur und Unermüdliche Verbesserung („Relentless Improvment“) zugrunde und den Fokus auf der Ablauf- statt auf der Aufbauorganisation.

Insofern ist SAFe in den letzten Ausbaustufen noch ambitionierter geworden und verspricht noch mehr als in der Vergangenheit; im Gegenzug bietet es aber auch eine Vielzahl wertvoller neuer Werkzeuge an, die in die ganze Organisation wirken können und damit kann der Einsatz von SAFe sein Wertversprechen besser erfüllen.

"SAFe ist unnötig kompliziert."

Diese Kritik war und ist nachvollziehbar. Die Uneinheitlichkeit der SAFe-Nomenklatur war lange eine Hürde. Gelegentlich widersprach die Bedeutung einzelner Begriffe anderen, etablierten Modellen, so wird sich nicht jeder in der SAFe-Definition des „Product Management“ wiederfinden. Einiges hat sich in den neueren Versionen aber verbessert: „Value Stream“ war lange Zeit sehr missverständlich und mehrfach besetzt, unter anderem als eine Skalierungsebene. (Inzwischen heißt diese „Large Solution“.) Die Absurdität eines „Project Management Office“ widersprach gänzlich den eigenen Lehren – inzwischen ist der Begriff glücklicherweise fallen gelassen. 

Der „Tailoring-down“-Ansatz ist erhalten geblieben. Er macht Kenntnis des ganzen Modells nötig, um überhaupt festzustellen, was man im individuellen Fall weglassen kann und was nicht. Entsprechend wird selbst bei Basis-Kursen wie „Leading SAFe“ und der einfachsten Zertifizierung als „Certified SAFe Agilist (SA)“ Kenntnis aller Ebenen und Konfigurationen vorausgesetzt.

Das alles lenkt viel Energie aller Beteiligten auf die Beschäftigung mit den Methoden und Prozessen – widersprüchlich bei einem Vorgehen, das sich als agil begreift. SAFe hat sich zwar didaktisch deutlich verbessert, die Hürde zum Einsatz ist aber immer noch hoch. Und daher ist folgender Grundsatz wichtig: Skaliere nicht wenn Du nicht wirklich musst!

„Eine skalierte agile Organisation sollte auf voneinander unabhängige Teams setzen. Mit der Zementierung von Abhängigkeiten zwischen den Teams geht SAFe den falschen Weg.“

Dem Ansatz möglichst autonomer Teams, die eigenständig Lösungen end-to-end umsetzen können, folgt beispielsweise das vielzitierte „Spotify Modell“, auch LeSS zieht klar und deutlich autonome, an der Wertschöpfung orientierte Feature Teams den Komponententeams vor. Der Anspruch ist aus agiler Sicht eingängig. Für die Realität vieler Organisationen greift er aber zu kurz. Unternehmen haben sich oft über Jahre und Jahrzehnte sehr traditionell entwickelt. Ihre Teams müssen beispielsweise mit vielen Abhängigkeiten zu Legacy-Systemen umgehen. Sehr komplexe Lösungen lassen sich oft nicht so einfach auseinandernehmen und die Schaffung von komplett autonomen Teams über Nacht ist einfach nicht machbar.

Den Ansatz von SAFe „Nothing beats an Agile Team except a Team of Agile Teams“ ist definitiv keine universelle Wahrheit. Aber in vielen Fällen ist das „Team of Agile Teams“ Mittel der Wahl – oder zumindest ein notwendiges Übel. Wichtig ist dabei, SAFe nicht als perfektes Zielbild misszuverstehen. Die mögliche Reduktion von Abhängigkeiten sollte kontinuierlich vorangetrieben und das Framework selber regelmäßig auf seine Eignung für die jeweilige Organisation überprüft – und nach Bedarf angepasst – werden.

"SAFe lässt den Betrieblichen Aspekt völlig außer Acht."

Tatsächlich könnte man meinen, dass SAFe sich komplett auf das Liefern konzentriert. Dies ist aber zu kurz gegriffen. SAFe definiert die Continuous Delivery Pipeline nicht nur als CI/CD (Continuous Integration / Continuous Deployment) sondern fügt vorne noch das Continuous Exploration und hinten das Release on Demand hinzu. Dadurch wird eine durchgehende Pipeline geschaffen, mit der man von der Idee bis in die Produktion alle Aspekte abdeckt. Dank dem ganzheitlichen DevOps Ansatz mit den 16 Aktivitäten in den vier Dimensionen hat man einen End-To-End Prozess inkl Betrieb, der beim Kunden anfängt und beim Kunden aufhört.

Keine Blaupause

Frameworks sind keine Blaupausen, die man nur auf Unternehmen legen muss und der Erfolg ist sicher. SAFe ist hier keine Ausnahme. Wie anfänglich gesagt, ist SAFe eine Schatztruhe, heutzutage mehr denn je. Doch der Weg zur Bergung sieht für jede Organisation anders aus, bedeutet harte Arbeit und ist nicht ohne Risiko. Nicht bei jedem Element von SAFe ist der Wert für jeden sofort erkennbar. Manches kann man nach erster Prüfung auch getrost als Ballast zurücklassen - um vielleicht zu einem späteren Moment darauf zurück zu kommen.

Welche Herausforderungen haben Sie in Bezug auf die Skalierung von Agilität? Und: Wie sehen Sie die Eignung von SAFe für Ihre Organisation?

Möchten Sie mehr zu SAFe erfahren? Besuchen Sie die Kurse der Zühlke Academy.

Ansprechpartner für die Schweiz

Romano Roth

Chief of DevOps & Partner

Seine Leidenschaft ist es, Unternehmen dabei zu unterstützen, Menschen, Prozesse und Technologien zusammenzubringen, damit sie ihren Kunden einen kontinuierlichen Mehrwert bieten können. 

Kontakt
Vielen Dank für Ihre Nachricht.