Warum skalierte Agilität nicht immer SAFe bedeuten muss?

Dieser Blog Post greift das Thema “Wie skalieren” auf. Passend zum Thema “Skalieren” wird sich ein weiterer Blog Post gezielt mit der Frage des “Warum” beschäftigen. Jeder, der sich fragt: “Aber ist das nicht die falsche Reihenfolge?”, findet in diesem Blog Post versteckt einen der Gründe dafür, weshalb es an der Stelle eben doch mit dem “Wie” startet. 😉

Steigen wir gleich ins Thema ein und beleuchten die Frage, weshalb eben skalierte Agilität oft mit SAFe assoziiert wird. Schaut man sich Publikationen über agile Frameworks an, welche sich der Skalierung verschrieben haben, so ist das Scaled Agile Framework, kurz SAFe, omnipräsent. Dieser Beitrag soll einen kurzen Einblick geben, weshalb diese vermeindliche Dominanz herrscht, und welche Alternativen es dennoch gibt.

Wieso das SAFe Framework so omnipräsent ist

Betrachten wir uns kurz die Darstellung von SAFe, wie sie uns typischerweise präsentiert wird.

Picture by https://www.scaledagileframework.com/

Die Darstellung von SAFe hat bei dir möglicherweise einige oder alle der folgenden Eindrücke hinterlassen.

• Die Menge und die Darstellung der Informationen zu SAFe suggerieren ein hohes Mass an Kompetenz und Wissen

• Die dargestellten Strukturen sprechen eine visuelle Sprache, welche sich stark an klassischen Aufbau- und Ablauforganisationen orientiert (Hierarchien*, Wertschöpfungsketten, usw.)

• “Das sieht teuer aus, das muss was wert sein.” → eigentlich ist diese Aussage nur bedingt richtig, an der Stelle als Faktor aber bestimmt zutreffend

_{* Hierarchien beziehen sich weniger auf Sozialsysteme, sondern mehr auf Objektsysteme (siehe dazu https://de.wikipedia.org/wiki/Hierarchie )}

Alle Punkte führen zu einer gewissen Sicherheit bei allen Beteiligten, und dies (zumindest teilweise) auch berechtigt. Mit Beteiligten meinen wir die Entscheidungsträger für die Wahl des Frameworks, die Personen welche im Framework agieren werden sowie die Personen, welche die Transformation begleiten werden.

Neben der Sicherheit, die bereits nur durch die dargestellte Form des Frameworks hervorgerufen wird, bringt das SAFe Framework noch weitere Aspekte mit sich, welche zur weiten Verbreitung des SAFe Frameworks geführt haben.

1. Es ist ein umfangreicher Zusammenzug aus agilen Praktiken, inkl. deren Anwendungsbereichen (z.B. wie man das Schätzen oder Priorisieren angehen kann).

2. Für viele Firmen ist es zudem ein Türöffner um überhaupt über Agilität zu sprechen/nachzudenken. Gerade weil das SAFE Framework auch das Managment Sichten berücksichtigt.

3. Die Prinzipien sind wirklich gut und bauen sehr schön auf bereits etabliertem wie Scrum oder dem agilen Manifest auf → Leider gehen diese Prinzipien in der Praxis immer etwas verloren.

4. Das SAFe Framework adressiert auch Themen, um welche andere Frameworks einen grossen Bogen machen (z.B. Finanzen).

Wir sehen also, es gibt durchaus valide Gründe dafür, weshalb SAFe so weit verbreitet ist. Wie steht es den nun mit den Alternativen?

Übersicht über skalierte Frameworks

Der Blog Post hat nicht den Anspruch, alle Alternativen zu SAFe aufzuzeigen. Zum einen betrachten wir uns nebst dem SAFe Framework noch das LeSS Fremwork, welches sich ähnlich positioniert. Weiter gibt es mit Nexus und Scrum@Scale noch zwei Ansätze der Scrum Organisationen scrum.org und Scrum Alliance. Zu guter Letzt wurde in diese Auswahl noch das Modell der Flight Levels von Klaus Leopold aufgenommen, welches die Kanban Methode als zentrales Element nutzt.

SAFe

• Quelle: https://www.scaledagileframework.com/

• Schlüsselelemente: Schlüsselelemente wie der Agile Release Train, das PI Planning, das Lean-Portfolio Management oder die Artefakte sind sehr gut beschrieben. Durch die weite Verbreitung des SAFe Frameworks gibt es viel Know-how dazu. Sei es in Form von Publikationen zu “Best Practices”, Unterlieferanten, welche ebenfalls bereits Erfahrung mit dem SAFe Framework haben oder auch im Bezug auf den Arbeitsmarkt, wo ich Personen finde, welche mit dem SAFe Framework vertraut sind.

• Risiken: Die dargestellten Strukturen verleiten dazu, die bestehende Aufbauorganisation darin abzubilden, was de facto zu keiner Veränderung führt. Elemente des SAFe Frameworks, welche nicht so detailliert beschrieben sind, erfordern mehr Aufwand (Lernzyklen) bei der Einführung als angenommen (z.B. Customer Centricity).

LeSS (Huge)

• Quelle: https://less.works/

• Schlüsselelemente: LeSS dient der Organisation von mehreren Teams bei der Entwicklung eines gemeinsamen Produktes. Im Zentrum steht dabei die Bildung von Requirement Areas mit entsprechenden Area Product Owners. Für den Rest bezieht man sich auf das Scrum Framework und fokussiert sich dabei stark auf deren Prinzipien und die Weiterentwicklung derer.

• Risiken: Der Fokus auf die Prinzipien erfordert ein hohes Mass an agiler Maturität. Abhängigkeiten werden nicht so explizit dargestellt, wie dies z.B. beim SAFe oder Nexus Framework der Fall ist.

Nexus

• Quelle: https://www.scrum.org/resources/scaling-scrum

• Schlüsselelemente: Mit dem Nexus Integration Team wird ein starker Fokus auf die Integration und ihre Tücken gelegt. Nexus ist im Grunde eine Ergänzung des bekannten Scrum Frameworks, welches bis auf einige Ausnahmen auch weiterhin 1:1 zur Anwendung kommt. So hat bei Nexus natürlich nicht mehr jedes Scrum Team einen Product Backlog und Product Owner, sondern es gibt eben einen über alle Teams.

• Risiken: Man ist verleitet, das Nexus Integration Team als eigenes, zusätzliches Team aufzubauen, anstelle durch Repräsentanten aus den bestehenden Teams. Dadurch wird Wissen nicht geteilt und die Autonomie der Teams eingeschränkt. Zudem macht der Einsatz des Nexus Frameworks wirklich nur Sinn, wenn es sich um ein Produkt handelt.

Scrum@Scale

• Quelle: https://www.scrumatscale.com/

• Schlüsselelemente: Scrum@Scale fokussiert sich auf die Accountabilities des Product Owners und Scrum Masters und unterstützt diese durch die Bildung des Product Owner Cycles und Scrum Master Cycles. Des Weiteren wird durch das Executive Action Team (EAT) und das Executive MetaScrum (EMS) dem Management eine zentrale und aktive Rolle zugeschrieben.

• Risiken: Da es sich mehr um ein Metamodell handelt, ist man gezwungen vieles neu und selbst anzudenken, was ein hohes Mass an agiler Maturität voraussetzt oder gegebenenfalls um so intensiver begleitet werden muss.

Flight Level

• Quelle: https://www.flightlevels.io/

• Schlüsselelemente: Auf allen Ebenen (Flight Levels) wir dieselbe Methodik, sprich Kanban eingesetzt. Im Mittelpunkt steht die Optimierung bestehender Wertschöpfungsketten, weshalb eine eigentliche Vorbereitungsphase (z.B. Bildung neuer Strukturen, Artefakte, Rollen, usw.) nicht nötig ist. Kanban Flight Levels sind universell einsetzbar.

• Risiken: Bestehende und gegebenenfalls unerwünschte strukturelle Hierarchien werden nicht ohne Weiteres aufgebrochen. Die Verwendung benötigt ein hohes Mass an agiler Maturität oder entsprechend intensivere Begleitung.

Beim Lesen der Beschreibungen zu den Frameworks, speziell zu deren Risiken ist dir sicherlich ins Auge gefallen, dass viele dieser Frameworks ein hohes Mass an agiler Maturität erfordern. Dies könnte dich dazu verleiten, zu voreilig eines der einfacheren (im Sinne einer nicht so hoch geforderten agilen Maturität) Frameworks zu wählen. Dazu möchte ich sagen, dass aber eben gerade diese Eintrittshürde dafür sorgt, dass sich die Organisation nachhaltiger zu einer agilen Organisation entwickeln kann → ein aus meiner Sicht sehr erstrebenswertes Ziel 😉

Bleibt zum Schluss die Frage, welches Framework denn nun das Beste für dich ist. Die kurze Antwort ist, wie es sich für einen Agile Coach gehört:

“It depends.”

Natürlich würde es nicht meinem Anspruch entsprechen, dich an der Stelle alleine zu lassen. Von daher mein Angebot: Solltest du vor der Herausforderung der Wahl eines entsprechenden Framework stehen, nutze doch unser Speed-Coaching Angebot, bei dem du kostenlos deine Fragen dazu mit einem unserer Agile Coaches diskutieren kannst.