Das kleine Einmaleins der agilen Skalierung – SAFe, LeSS, Spotify

Wenn Ihnen beim Lesen des Titels schon der Kopf schwirrt und Sie sich fragen, was ein Musikstreaming-Anbieter mit weniger Sicherheit zu tun hat, dann sind Sie hier genau richtig. Und wenn Sie beim Lesen des Titels feststellen, dass Sie manche oder alle der Buzzwords bereits aus den Diskussionen in Ihrem Unternehmen kennen – dann sind Sie hier natürlich auch genau richtig.

In unsere letzten beiden Notizen haben wir eine Einführung in das Thema „Skalierte Agilität“ geboten und aufgezeigt, wie sich das Konstrukt Agilität im Organisationskontext in den letzten Jahren verändert hat und in Zukunft noch verändern wird. Heute nehmen wir uns einige Buzzwords zur Brust, die in diesem Kontext häufig benutzt, aber nicht immer verstanden werden

Wozu braucht es skalierte agile Frameworks?

Organisationsentwickler, Unternehmensberater, Organisationsforscher und Manager befassen sich seit Jahren mit der Frage: „Wie kann unser ganzes Unternehmen oder zumindest ein ganzer Bereich anpassungsfähiger und schneller werden?“ Das heißt: Gesucht werden agile Lösungen, die eben nicht „nur“ Teams helfen, anpassungsfähiger und schneller zu werden, sondern dies für ganze Organisationen und Organisationsbereiche können. Scrum oder Kanban, wie es in Teams genutzt wird, bietet nicht den notwendigen Rahmen und die notwendigen Hilfsmittel, um ganze Unternehmen zu steuern. Aus diesem Bedarf sind verschiedene Rahmenwerke bzw. Frameworks entstanden, die genau diese Lücke schließen sollen.

Was sind SAFe und LeSS?

Zwei der bekanntesten Frameworks für skalierte Agilität sind SAFe und LeSS. Beides sind Akronyme. SAFe steht für Scaled Agile Framework und LeSS steht für Large Scale Scrum. Beide Frameworks enthalten Prinzipien, Strukturen und Prozesse zum Aufbau einer großen agilen Einheit. Damit sind sie also Managementwerkzeuge für agile Skalierung. Beide bauen auf dem Grundprinzip auf, dass Unternehmensbereiche nicht zu groß sein sollten, um schnell, effektiv und anpassungsfähig zu bleiben. Diese Erkenntnis beruht auf der sogenannten „Dunbar’s Number“, die besagt, dass Menschen in Gruppengrößen bis ca. 150 Menschen gute Beziehungen pflegen können. Bei SAFe bilden sogenannte Agile Release Trains mit 50-125 Menschen das Herzstück des Frameworks, bei LeSS wird ein Bereich auf maximal 8 Teams, also ca. 40-100 Menschen ausgebaut.

Die beiden Frameworks werden ständig weiterentwickelt. Speziell SAFe hat durch zahlreiche Zusätze, Ergänzungen und Überarbeitungen inzwischen einen Kompliziertheitsgrad erreicht, der einen Laien überfordert. Und mit „Laien“ meinen wir durchaus auch gut ausgebildete Manager, die schon erste agile Erfahrungen haben. SAFe enthält viele wichtige Erkenntnisse und sehr nützliche Elemente (u.a. zu Portfoliomanagement, Budgetierung, Iterationssteuerung), ist allerdings in seiner Gesamtheit ein zu kompliziertes und vor allem zu mechanistisches Konstrukt. Für Anwender muss es teils eher wie eine Bürokratisierung der Agilität wirken. Dies ist auch darin begründet, dass SAFe seinnen Ursprung im Lean Management, also in der Optimierung von Abläufen und Vermeidung von Verschwendung hat, und eben nicht im agilen Management. Dadurch kommen Aspekte wie kreative Produktentwicklung, Innovation und Kundenzentrierung schlicht zu kurz. Dennoch nutzen viele Organisationen SAFe-Elemente mal mehr mal weniger konform in ihrer agilen Transformation. In Gänze umgesetzt haben wir das SAFe-Modell noch nie erlebt.

LeSS ist demgegenüber ein deutlich einfacheres Framework. Es baut auf der Scrum-Logik auf und skaliert diese auf Bereichs- bzw. Organisationsgröße. LeSS funktioniert für bis zu acht Teams. Wird der Bereich größer, so bietet LeSS mit dem LeSS Huge Model eine vergrößerte Version, die im Prinzip dasselbe in groß ist. Durch die weitere Skalierung entstehen neue Bedarfe. So braucht es zum Beispiel Area Product Owner, die für Produktbestandteile verantwortlich sind und so den Product Owner für das Gesamtprodukt entlasten. Darüber hinaus bietet LeSS Prinzipien für Management, Führung und Software- bzw. Produktentwicklung. Genau wie bei SAFe lohnt auch hier ein Blick auf die zugrundeliegenden Elemente und Prinzipien, um den eigenen Skalierungswerkzeugkasten zu erweitern.

Was ist das Spotify- bzw. Stämme-Modell?

Das Spotify-Modell beschreibt eine Organisationsform, die der schwedische Musikstreaming-Anbieter früher nutzte, um trotz wachsender Größe schnell und anpassungsfähig zu bleiben. Diese Organisationsform funktionierte zum damaligen Zeitpunkt für Spotify sehr gut, weshalb sie als Best Practice mit anderen Unternehmen geteilt wurde. Leider wurde und wird das Modell wegen seiner Einfachheit oft unhinterfragt kopiert und findet sich auch daher heute in vielen deutschen und internationalen Konzernen wieder.

Das Herzstück des Stämme-Modells (lassen Sie es uns so nennen, denn es ist weder Spotify-exklusiv noch nutzt Spotify das Modell heute so) bilden die sogenannten „Tribes“ (zu deutsch: Stämme) mit bis zu 120 Personen. Die Tribes funktionieren ähnlich wie eine Matrixorganisation. Teams heißen „Squads“ und sind cross-funktional zusammengestellt. Menschen mit derselben Fachrichtung organisieren sich in „Chapters“, um sich fachlich weiterzuentwickeln (im Prinzip: Communities of Practice). Darüber hinaus gibt es noch Gilden, die sich nach gemeinsamen Interessen zusammenfinden (also eine Community of Interest). Sie merken schon: Das Stämme-Modell hat nicht viel Neues zu bieten – ist aber einfach verständlich, klingt attraktiv und nicht so weit entfernt von typischen Business Units. Es bietet übrigens keine Hinweise zur Ablauforganisation, sondern nur zur Aufbauorganisation. Wir glauben, dass gerade deshalb viele Manager*innen auf das Spotify-Modell anspringen. Die Veränderung hin zu einem Stämme-Modell ist für viele eher das gewohnte „Kästchenschieben“ statt der radikalen agilen Transformation.

Fazit: Welches Framework zur agilen Skalierung sollte ich anwenden? Unsere 6 Ratschläge

Die schnelle Antwort: Keines der beschriebenen Frameworks in seiner Gänze. Beachten Sie stattdessen lieber unsere gut gemeinten Ratschläge:

1. Machen Sie sich mit verschiedenen Skalierungsframeworks vertraut.
2. Überlegen Sie sich sehr gut, auf welche Frage Sie eine Antwort suchen, bevor Sie sich zu einem oder gemischten Frameworks committen.
3. Welches Problem wollen Sie denn wirklich lösen? Sie müssen nicht gleich SAFe einführen, wenn Sie 5 agile Teams besser koordinieren wollen. Sie müssen ihre Teams nicht in Squads umtaufen, wenn Sie Personen aus verschiedenen Funktionen in einem Team zusammenarbeiten lassen wollen. Sie müssen nicht LeSS einführen, um Ihren Kunden in den Mittelpunkt zu rücken.
4. Verlieren Sie die agilen Prinzipien nicht aus den Augen.
5. Leider schaffen es die allermeisten Frameworks nicht, agile Prinzipien auf einfache Weise widerzuspiegeln, weshalb die meisten Betrachter sich gleich auf die strukturellen Elemente wie Rollen, Prozesse und vermeintliche Hierarchien stürzen. Zum Beispiel ist in keinem der Frameworks ein Kunde abgebildet. Dabei wollen Sie doch eigentlich eine Antwort darauf, dass sich Ihre Kunden schnelleren Service, passendere Produkte, bessere Kundenerlebnisse wünschen. Also: Haben Sie agile Prinzipien immer zuerst im Kopf – und überlegen Sie sich vor dem großen Kästchenschieben und Organigramme zeichnen lieber zuerst: Ist das im Sinne der Kunden? Macht uns das schneller? Sorgt das für mehr Unternehmertum? …
6. Auch bei agilen Transformationen gilt: Structure follows strategy.
7. Leider beobachten wir bei vielen SAFe-, LeSS-, und Stämme-Modell-Einführungen, dass die eigentliche Strategie in den Hintergrund rückt. Und damit auch die große Frage nach dem „Warum?“ der Veränderung. Also – erst schauen, welche Strategie sie verfolgen, dann entscheiden, welche strukturellen Veränderungen notwendig sind (siehe auch Punkt 2)
8. „Nail it before you scale it!”
9. Verzichten Sie auf große „Big Bang“-Einführungen. Starten Sie im Kleinen mit agilen Teams. Skalieren Sie es, wenn es klappt – wenn also agiles Mindset und Methodik in der Organisation verinnerlicht sind. Ansonsten kreieren Sie einfach nur ein skaliertes Chaos.
10. Nutzen Sie (nur) die notwendigen Begrifflichkeiten, Rollen und Methoden und übersetzen Sie, wo nötig, in Ihre Organisationssprache.
11. Lassen Sie aus dem strukturellen Teil des Frameworks erstmal weg, was nicht sein muss, um Ihre Strategie zu verfolgen. Es ist enorm wichtig, dass Sie die kulturellen und sozialen Aspekte der Veränderung nicht vergessen. Und dazu gehört Sprache. Nicht jeder wird nach dem dritten englischen Begriff und der Einführung eines „Release Train Engineers“ und eines „Area Product Owners“ noch zuhören, geschweige denn sich für die Veränderung begeistern können. Vergessen Sie also nicht die notwendige Change-Kommunikation, ein einfaches Visual – und vor allem: Vergessen Sie nicht, das „Warum“ der Veränderung in einem einfachen und faktisch belegbarem Satz zu benennen. Hier empfehlen wir Ihnen unsere Notiz zu „Sense of Urgency“.
12. Lassen Sie sich von niemandem erzählen, dass eines davon das einzig Wahre sei. Die Wahrheit ist: Alle Frameworks enthalten sehr wertvolle Elemente und Erkenntnisse. Und alle können Teilantworten auf Ihre Herausforderungen bieten. Es ist daher gut, wenn sie die verschiedenen Frameworks kennen und grob verstehen.

Das Ergebnis aus unseren Ratschlägen: Ein für Ihre Organisation passendes Organisationsmodell, das Ihnen dabei hilft, anpassungsfähig, kundenzentriert und strategisch ausgerichtet zu arbeiten.

• Schreiben Sie uns gerne Ihre Gedanken – per Mail, LinkedIn oder Xing.