SAF workshop
Insights

SAFe – agile Schatztruhe oder Ballast?

Johannes Kling

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 gross. Doch nicht alle Erwartungen an das Framework erfüllen sich.

Ich kenne SAFe und die entsprechenden Kurse des Scaled Agile Institute (SAI) aus mehreren Perspektiven: anfänglich war ich selber skeptischer Teilnehmer von Kursen wie Leading SAFe oder Implementing SAFe; später, als SAFe Program Consultant (SPC), habe ich selber bei der Swisscom Organisationsbereichen bei der Einführung agiler Methoden geholfen (von denen sich einige zumindest an SAFe orientierten). Und ich habe über zwei Jahre hinweg auch Kurse der SAI gegeben. 
 

Insight in brief

  • SAFe ist umstritten, aber viel besser als sein Ruf.
  • SAFe ist von den massgeblichen Ansätzen zur Skalierung von Agilität zweifellos der komplizierteste, schwergewichtigste und restriktivste.
  • SAFe sollte keineswegs unreflektiert als Blaupause verstanden werden. Es kann in einigen Unternehmen, die an ihrer Agilität arbeiten, auch ein geeigneter Zwischenschritt sein.
  • Unternehmen, die das Framework als einen Werkzeug(-kasten) von vielen und eine temporäre Lösung verstehen können von SAFe profitieren.
     
2 diagonalestriche lightgray

Ich erinnere mich noch gut: Anfänglich hatte ich grosse Vorbehalte gegenüber SAFe. Das Modell erschien mir unnötig kompliziert und schwer vermittelbar, inhaltlich unzureichend und einiges widersprach grundsätzlich meinem Verständnis der agilen Prinzipien. Kurz: Mir 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 habe ich mir bewahrt. Inzwischen sehe ich SAFe aber nicht mehr als Ballast, sondern in erster Linie als eine Schatztruhe erprobter Muster (aus der Welt der Agilität, Lean Production, aber auch traditioneller Vorgehensweisen wie dem RUP), die in einen logischen Zusammenhang geordnet sind.

Ist SAFe über Kritik erhaben? Sicher nicht. Auf drei Punkte möchte ich besonders eingehen und meine Einschätzung gegenüberstellen:
 

2 diagonalestriche lightgray

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

Diese Einschätzung beruht oft auf einem grundsätzlichen Missverständnis: dass SAFe massgeblich auf die Verbesserung des operativen Business abzielt. SAFe ist ein Framework zur Produktentwicklung. Dies kann leicht übersehen werden. Beispielsweise, weil SAFe eine organisatorische Transformation auf mehreren Ebenen zugrunde legt - vom Entwicklungsteam bis zur Geschäftsleitung. Weil es von "Value Streams" spricht, doch gemeint sind fast immer "Development Value Streams" - nicht operationelle Wertschöpfungsketten. Weil SAFe selber "dramatische Anstiege beim Mitarbeiter-Engagement, bessere Wirtschaftlichkeit und Arbeitsplätze mit mehr Produktivität, Inspiration und Spass" verspricht. Und natürlich, weil heutzutage die (IT-) Produktentwicklung Basis für das Kerngeschäft fast aller Unternehmen ist.

Aber: Die Produktentwicklung ist eben selten das Kerngeschäft an sich. Bei der Begeisterung für vermeintlich einfache Lösungen (wie beispielsweise eine "Agile Transformation") wird dieser Umstand leicht ignoriert und falsche Erwartungen werden geweckt.

  • Einem Technikproduzenten, der keine Idee hat, wie er mit Wettbewerbern in der Digitalisierung umgeht, wird SAFe nur helfen, wenn er auch Mut zur Innovation beweist.
  • Eine Bank braucht mehr als nur SAFe, 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 SAFe einführen, sondern sich systemisch ändern, um die intrinsische Motivation der Mitarbeitenden zu fördern.

Eine agile Produktentwicklung macht grundsätzliche Probleme des Unternehmens oft offensichtlicher. Und möglicherweise strahlt die Verbesserung in der Entwicklung auch vereinzelt positiv in operative Bereiche aus. Aspekte von SAFe können, richtig eingesetzt, äusserst wertvolle Werkzeuge sein. Aber dazu müssen wir die Erwartungen auch realistisch halten und uns bewusst sein, dass es mehr als SAFe braucht, um Probleme im operativen Geschäft und im Gesamtsystem zu lösen.
 

2 diagonalestriche lightgray

"SAFe ist unnötig kompliziert."

Für mich ist diese Kritik nachvollziehbar. Die SAFe-Nomenklatur ist leider sehr uneinheitlich. Die Bedeutung einzelner Begriffe (vom "Product Management" über "Value Stream" bis hin zum "Project Management Office") widerspricht oft anderen, etablierten Modellen. Und der "Tailoring-down"-Ansatz macht Expertenkenntnis des ganzen Modells nötig, um überhaupt festzustellen, was man im individuellen Fall weglassen kann und was nicht.

Selbst bei Basis-Kursen wie "Leading SAFe" und der einfachsten Zertifizierung als "Certified SAFe Agilist (SA)" wird Kenntnis aller vier Ebenen vorausgesetzt - dabei ist die "Value Stream"-Ebene nur für einen kleinen Teil sehr grosser Unternehmen tatsächlich jemals relevant.

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. Ich bin der Meinung, dass SAFe sich didaktisch noch stark verbessern kann und muss, um die Hürde zum Einsatz niedriger zu setzen.
 

2 diagonalestriche lightgray

"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."

"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. Den Anspruch verstehe ich gut und er 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. Die Schaffung von komplett autonomen Teams von heute auf morgen ist einfach nicht vorstellbar. Sehr komplexe Lösungen lassen sich oft nicht einfach auseinandernehmen.

Dem Ansatz von SAFe "Nothing beats an Agile Team except a Team of Agile Teams" sehe ich nicht als universelle Wahrheit. Aber in vielen Fällen ist das "Team of Agile Teams" Mittel der Wahl oder zumindest ein notwendiges Übel. Wichtig erscheint mir dabei, SAFe nicht als perfektes Zielbild misszuverstehen. Die mögliche Reduktion von Abhängigkeiten sollte kontinuierlich vorangetrieben und das Framework selber regelmässig auf seine Eignung für die jeweilige Organisation überprüft und angepasst werden.

2 diagonalestriche lightgray

Keine Blaupause

Frameworks sind keine Blaupausen, die man nur auf Unternehmen legen muss und der Erfolg ist sicher. SAFe macht hier keine Ausnahme. Wie anfänglich gesagt, ist SAFe eine Schatztruhe. Doch der Weg zur Bergung sieht für jede Organisation anders aus, ist harte Arbeit und 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 unsere Kurse.

Johannes Kling Zühlke

Johannes Kling

Lead Consultant
Ansprechpartner für Deutschland johannes.kling@zuehlke.com +49 89 309 052 64 60

Johannes Kling hilft dabei, sicherzustellen, dass der Business Impact klar benannt ist und sich im Scope eines Projekts widerspiegelt. Als Lead Consultant mit mehr als 15 Jahren Erfahrung in Business Analyse, Projektmanagement und Organisationsberatung ist er ein kompetenter Ansprechpartner für Management und Mandatsleitung. Johannes übernimmt am Besten die Rolle eines sehr erfahrenen Proxy-PO oder Beraters.

In unterschiedlichen Rollen hat er seinen Beitrag zum Erfolg agiler und traditionell organisierter Projekte in verschiedenen Branchen geleistet. Als Spezialist für Organisation brennt er dafür, einzelnen Teams, skalierten Teams und kleinen/mittleren Unternehmen (z.B. beim Portfolio Management) auf pragmatische Weise zu maximaler Wirksamkeit und Kundenorientierung zu verhelfen.