Warum das Spotify Modell nicht als Blaupause für deine agile Organisation dient

Die Namen der organisatorischen Einheiten im Spotify Modell erinnern beim ersten Lesen eher an ein Multiplayer-Online-Game als an eine seriöse Organisationsstruktur. Allerdings zeigt das Zusammenspiel dieser Einheiten, wie durchdacht und stimmig das Spotify Modell ist. Und ganz nebenbei gelingt mit dieser Namensgebung auch die Abkehr von einer eher antiquierten Corporate-Sprache. 

In den folgenden Absätzen stelle ich Dir die organisatorischen Einheiten der Spotify Organisation vor:

• Squads - Agile Teams mit 8-10 Personen
• Tribes - Zusammenschluss von Squads (150 Personen)
• Chapters - Fachliche Netzwerke innerhalb eines Tribes
• Guilds - Übergreifende freiwillige Communities

Den Kern der Spotify Organisation bilden kleine autonome Teams, sogenannte “Squads”. Diese crossfunktional besetzten Teams von bis zu 8 Personen haben end-to-end Verantwortung für einen ausgewählten Bereich oder ein Feature. Eine Squad ist von der Idee, über Konzeption und Entwicklung bis zum kommerziellen Erfolg ihrer Arbeit verantwortlich. Im Kern kannst Du dir eine Squad wie ein Scrum Team vorstellen, die Größe einer Squad orientiert sich an der Millerschen Zahl. Auch wenn Spotify sich beim Aufbau seiner Organisation von Scrum hat inspirieren lassen, sind die Spotify Squads frei in der Wahl ihrer Methoden und der prozessualen Gestaltung ihrer Zusammenarbeit. Die Autonomie der Spotify Squads wird lediglich durch den Purpose, die langfristigen Ziele und den tragenden Prinzipien der Spotify Organisation eingeschränkt.

Ein Spotify Tribe ist der Zusammenschluss mehrerer Squads zu einer größeren organisatorischen Einheit. Dabei erfolgt der Zusammenschluss mehrerer Squads in einem Tribe nicht wahllos, sondern auf Basis eines gemeinsamen Kontextes. Das heißt, alle Squads innerhalb eines Tribes arbeiten gemeinsam an einer Leistung oder ihre Arbeit steht zumindest in sehr enger Verbindung zueinander. Jeder Tribe wird von einem oder mehreren Tribe-Lead geführt, beispielsweise einem Product-Lead (Produktmanager) und einem Technical-Lead (Architekt). Spotify Tribes haben maximal 150 Mitglieder. Diese Zahl orientiert sich an der Dunbar-Zahl, die besagt, dass Du maximal mit 150 Personen soziale Beziehungen pflegen kannst. 

Chapters sind der Aspekt der Spotify Organisation, der noch am ehesten an eine traditionelle Organisation und an klassische “Abteilungen” erinnert. Denn hier erfolgt endlich der fachliche Zusammenschluss aller Kollegen mit der gleichen Profession. So gehören z.B. alle Designer innerhalb einer Tribe dem gleichen Chapter an. Dabei übernimmt der Chapter-Lead auch gleichzeitig Führungsverantwortung für die Mitarbeiter in seinem Chapter. Diese Führungsverantwortung bezieht sich auf die fachliche Weiterentwicklung der Mitarbeiter und die Entwicklung einheitlicher Standards. Jedoch hat der Chapter-Lead keine Weisungsbefugnis auf die zu erbringende Arbeit und operativen Ziele. Diese werden durch die Squad definiert, in der der Mitarbeiter mitwirkt. Damit schafft die Spotify Organisation eine extrem hohe Flexibilität. Denn wenn ein Mitarbeiter die Squad innerhalb der gleichen Tribe wechselt, bleibt er immer dem gleichen Chapter zugeordnet. 

Spotify Guilds sind freiwillige Communities, die auch über die Grenzen einer Tribe hinausgehen. Damit macht das Spotify Modell das wichtige agile Prinzip der Freiwilligkeit und Selbstverpflichtung zu einem wesentlichen Bestandteil seiner Organisationsstruktur. Denn Spotify Guilds entstehen auf Basis des gleichgerichteten Interesses mehrerer Mitarbeiter, auch ohne Vorgaben des Managements. Gepflegt werden die Guilds über regelmäßige Treffen und Mailinglisten. Darin findet nicht nur fachlicher Austausch statt. Viel wichtiger ist, dass hier auch ein Austausch und Vernetzung über die Grenzen bestehender Tribes erfolgt. 

Die Spotify Organisation ist durch einige wesentliche Prinzipien gekennzeichnet. Viele Unternehmen machen in meinen Augen den Fehler, sich zu sehr mit Tools und Methoden zu beschäftigen. Oder gar den Aufbau der Spotify Organisation blind zu kopieren, ohne sich aber mit den dahinter liegenden Prinzipien zu befassen. Allerdings sind gerade diese Prinzipien das Fundament, auf dem das Spotify Modell überhaupt erst zum Leben erweckt wird.

Autonomy is motivating. And motivated people build better stuff.

Spotify Model

Auf den ersten Blick scheinen die Autonomie der Squads und ein strategisches Alignment von 3.000 Mitarbeitern unmöglich. Im Spotify Model kommt deswegen dem Purpose und den Führungskräften eine besondere Aufgabe zu. Denn Führungskräfte reden vor allem über das Warum, zu lösende Probleme oder die Mission von Spotify. Damit erzielt das Spotify Model ein hohes Alignment in der übergreifenden Ausrichtung. Dieses inhaltliche Alignment in Verbindung mit einem klaren Rahmen für die Gestaltung der Zusammenarbeit ist die Voraussetzung dafür, dass jede einzelne Spotify Tribe und Squad ihre Autonomie ausleben können. 

Rules are a good start, but break them when needed.

Spotify Model

Zu Beginn orientierte sich die Spotify Organisation sehr stark am Scrum Framework. Allerdings stellten die Mitarbeiter schnell fest, dass Scrum alleine keine zufriedenstellenden Antworten auf auftretende Herausforderungen hat. Seitdem ist Scrum eine Wahl, aber keine Vorgabe mehr für Squads. Scrum Master sind nun agile Coaches und Teams werden ermutigt, neue Methoden und Werkzeuge zu probieren, um ihre eigenen Erfahrungen zu sammeln. Das heißt, Teams genießen einen hohen Freiheitsgrad, um zu lernen, welches Vorgehen für sie am passendsten ist.

Das Spotify Modell setzt darauf, dass sich überlegene und wertstiftende Tools, Methoden und Werkzeuge automatisch rumsprechen. Statt also “best practices” in einen formalisierten Rahmen zu pressen, setzt Spotify auf eine “Cross Pollination”. Also eine automatische Fortpflanzung wertvoller Erfahrungen und Vorgehensweisen. Wieder liegt es am Team, zu entscheiden, welche Praktiken und Tools die eigene Arbeit sinnvoll unterstützen können.

Ein weiteres wichtiges Standbein für einen hohen Autonomiegrad der Squads ist das Prinzip des “internal open source model”. Das heißt, dass kein Team einen Besitzanspruch am eigenen Code und der eigenen Arbeitsleistung erhebt. Vielmehr steht das eigene Arbeitsergebnis unter dem Open Source Gedanken anderen Squads zur Verfügung, damit diese den Code nutzen, verändern oder weiterentwickeln. So gelingt es, Abhängigkeiten und daraus resultierende Wartezeiten auf ein Minimum zu reduzieren.

Große Projekte mit vielen Abhängigkeiten gibt es nur, wenn es gar nicht anders geht. Dann aber empfiehlt das Spotify Modell die tägliche Synchronisation zwischen den Squads, regelmäßige Demo Days und ein kleines Führungsteam (Product, Tech, Design), dass das “big picture” im Auge behält.  Das heißt, die systematische Synchronisation also eine Etablierung des zweiten Flight Levels sind kritisch für en Erfolg großer Vorhaben mit vielen Abhängigkeiten.

We aim to make mistakes faster than anyone else.

Daniel Ek

Das Spotify Modell fordert und fördert Experimente. Was nicht funktioniert, wird gelassen. Was gut funktioniert, wird weiterentwickelt, solange bis die Erweiterung Nutzen stiftet. Dabei ist die Lean Startup Methode Grundlage für das systematische Experimentieren. Formuliere deine Annahmen, baue es, messe das Ergebnis und passe dein Vorgehen an.

Das Spotify Modell setzt auf eine ausgeprägte Fehlerkultur und eine “fast failure recovery” . Fehler und daraus resultierende Learnings sind Teil einer langfristigen Strategie. Je schneller Fehler erkannt werden, desto schneller die Chance, sich zu verbessern. Deshalb werden Fehler genau analysiert. Nicht etwa, um Verantwortliche zu identifizieren und mit den Fingern auf sie zu zeigen. Sondern, um die Ursache zu identifizieren und zu verhindern, dass der gleiche Fehler nochmals auftritt. Wenn das Problem und die Ursache verstanden sind, dann lautet ein weiteres Mantra “Fix the process not the product”, um ein erneutes Auftreten des Fehlers zu verhindern.

Innovation hat im Spotify Modell einen höheren Stellenwert als Vorhersagbarkeit. Deswegen gibt es keine festen Release-Pläne mit Ausnahme von Partner-Integrationen. Das heißt, wenn es auch Abhängigkeiten zu externen Partnern gibt, ist ein fester Zeitplan Ausdruck von Verbindlichkeit. Sonst heißt das einfache Mantra des Spotify Modells: “100% predictability means no innovation”. Es gibt einzig und alleine feste “Release Trains”, die regelmäßig abfahren. Wenn dein Inkrement fertig ist, kommt es dazu, sonst wartest Du einfach auf den nächsten Release Train.

People are natural innovators. So just get out of their way and let them try things out.

Das Spotify Modell ermutigt Mitarbeiter, über den Tellerrand zu schauen und permanent Neues zu probieren. So dürfen Mitarbeiter 10 % ihrer Zeit auf eigene “Hacks” verplanen, darüber hinaus veranstaltet Spotify regelmäßige “Hack Weeks”. In dieser Zeit können Mitarbeiter in freien Teams an eigenen Projekten arbeiten. Dabei steht nicht im Vordergrund, dass am Ende des Hacks eine sinnvolle Produkterweiterung steht. Vielmehr vertraut das Spotify Modell darauf, dass Mitarbeiter in diesem Prozess etwas lernen und dieses Wissen für die weitere Produktentwicklung irgendwann nützlich ist. Und wenn doch nicht, haben Mitarbeiter einfach Spaß gehabt und der darf im Spotify Modell auf keinen Fall zu kurz kommen.

Die Spotify Engineering Culture beschreibt über die allgemeinen Prinzipien der Spotify Organisation spezielle Prinzipienfür die Entwicklung digitaler Plattformen und Produkte. Deswegen ist die Spotify Engineering Culture insbesondere für Product Owner, technisch orientierte Scrum Master und Entwickler interessant.

1. Releasing should be routine not drama: Spezialisierte Squads sorgen dafür, dass Releases oft und einfach möglich sind. Diese Release Squads arbeiten jedoch nur am Prozess und stellen Infrastruktur und Tools zur Verfügung. Jede Squad releast jedoch eigenständig.
2. Release Trains fahren je nach Produktbereich einmal pro Woche oder alle drei Wochen ab. Pünktlich und regelmäßig.Was fertig ist, fährt mit, was nicht nicht. Entsprechend gibt es keine “release plans”.
3. Feature toggles erlauben es den Squads auch unfertigen Code zu committen, um damit das technical debt zu reduzieren und Integrationsprobleme frühzeitig zu erkennen Zudem erlauben die Toggles neue Features sukzessive zu launchen und nur einem ausgewählten Kreis der User zur Verfügung zu stellen.
4. Impact > Velocity: Ein Feature ist erst “done”, wenn es die gewünschte Wirkung erzielt. Nicht einfach nachdem es fehlerfrei deployed wurde. Eine interessante Auslegung der “Definition of Done”.
5. Fix the process not the product - Konstruktive und ehrliche Fehleranalyse als Basis für kontinuierliche, ganzheitliche Verbesserungen. 
6. Think it, build it, ship it, tweak it - Das Mantra für schnelle Produkt-Iterationen.  Was nicht funktioniert, wird gelassen. Was gut funktioniert, wird weiter ausgebaut.

Die Spotify Engineering Culture ist wirklich ein gut dokumentiertes Beispiel über gute Praktiken bei der Entwicklung digitaler Produkte und Plattformen.

Eine schlechte Nachricht vorweg: Du kannst das Spotify Modell nicht einfach auf deine Organisation übertragen. Dabei spielen vor allem vier Punkte eine wesentliche Rolle.

Erstens ist eine Organisationsstruktur immer nur eine Antwort auf die Ziele und die aktuellen Herausforderungen eines Unternehmens. Entsprechend ist das Spotify Modell auch nur eine Antwort auf die Herausforderungen von Spotify zu gegebener Zeit (ca. 2012). Möglicherweise hat Spotify nie in dieser skizzierten Struktur gearbeitet und ganz sicher sieht die Spotify Organisation heute schon wieder ganz anders aus. Es nun als Blaupause für deine Organisation zu verwenden ist in etwa so, als würdest Du eine Seekarte des 15. Jahrhunderts nutzen, um deine nächste Wandertour zu planen.

Zweitens sind Organisationen komplexe Systeme und für diese Art der Probleme gibt es keine Best Practices. Die Idee, dass Organisationen einmal designt werden und dann statisch feststehen, ist eine naive Idee. Organisationen leben und dürfen sich dauernd “neu erfinden”. Damit scheidet copy / paste als Lieblingswerkzeug der Bürokraten auch für das Spotify Modell aus.

Drittens darfst Du Dir außerdem die Frage stellen, ob die Struktur und damit das Spotify Modell vielleicht auch nur das Ergebnis einer gelebten Lern- und Engineering Kultur sind. Dabei könntest Du zu dem Schluss kommen, dass der strukturelle Aufbau des Spotify Modells vielleicht auch nur ein logischer Schritt in der evolutionären Entwicklung der Spotify Organisation war. Und nur möglich und “logisch”, weil kulturell bereits wichtige Voraussetzungen erfüllt waren.

Das Spotify Modell ist auch das Ergebnis eines “internal open source” Ansatzes in Verbindung mit einer modularen Softwarearchitektur. Denn so gelingt es, Teams maximale Autonomie zu gewähren und mögliche Abhängigkeiten per Design zu reduzieren. Das heißt, in der Sprache des Flight Level Models sorgen die Softwarearchitektur in Verbindung mit einem “Open Source” Prinzip dafür, dass Flight Level 2 nicht zu einem Problem für die Organisation wird. Und solange Du kein Softwareunternehmen bist, kannst Du diesen “Hack” gar nicht 1:1 implementieren.

Das Flight Level Model

Das Flight Level Model beschreibt drei Flughöhen einer Organisation.

1. Auf Flight Level 1 arbeiten agile Teams an der Umsetzung.
2. auf Flight Level 2 synchronisiert Du Teams und managst Abhängigkeit.
3. Auf Flight Level 3 priorisierst Du die strategischen Initiativen.

Im Spotify Modell sorgen die modulare Architektur, eine ausgeprägte Lernkultur und ein “freedom to operate” dafür, dass Flight Level 2 nicht zu einer Achillesferse für die Organisation wird. Mehr zum Flight Level Model.

Auch wenn Du die Struktur des Spotify Modell nicht einfach kopieren solltest, findest Du einige denkwürdige Inspirationen.

In der Spotify Organisation ist Führung konsequent zweigeteilt. Auf der einen Seite hast Du mit Squads wertschöpfende Einheiten, die auf Flight Level 1 “echte Arbeit” verrichten. Gleichzeitig etablierst Du über Chapter eine zweite Führungslinie und -struktur, die eine fachliche und disziplinarische Führung sicherstellt. Das heißt, als Leiter einer Squad kann ich mich darauf verlassen, Spezialisten auf Top-Niveau in meinem Team zu haben. Das ist sicher eine der wesentlichen Neuerungen, die das Spotify Modell hervorgebracht hat. In Konzepten wie der Helix Organisation wird dieser Gedanke weitergeführt.

Auch wenn die Namensgebung der Spotify Organisation sicher nicht jedermanns Geschmack ist und vielleicht eher den Anstrich eines Video Games hat, darfst Du Dir daran gerne ein Beispiel nehmen. Denn Sprache macht Bilder und ganz sicher gehören Begriffe wie “Abteilung” und “Vorgesetzter” auf die Resterampe des 20. Jahrhunderts. Lass bei der Namensgebung deiner Organisationsstruktur also gerne ein wenig Kreativität walten. Wir verbringen viel Zeit unseres Lebens auf und mit der Arbeit, als dass wir das an dieser Stelle “zu Ernst” nehmen sollten. 

Auch wenn Du vielleicht keine Software Organisation hast, liefert das Spotify Modell ein gutes Beispiel dafür, Abhängigkeiten systematisch zu reduzieren. Das “internal open source model”, eine modulare Software-Architektur oder die Vermeidung großer Projekte ist nichts weiter als das Ansinnen, Abhängigkeiten systematisch zu reduzieren. Und auch wenn Du kein Softwareunternehmen bist, bleibt für Dich die Arbeitsfrage, wie es in deiner Wertschöpfung und Organisation gelingt, das Flight Level 2 durch kluge Strukturen und Prinzipien systematisch zu entlasten.

Die folgenden Schritte helfen Dir, dich der Spotify Organisation Schritt für Schritt zu nähern und gängige Mis(t)verständnisse zu vermeiden.

1. Welche Nachfrage trifft auf dein Unternehmen? Bevor Du aus fachlichen Abteilungen einfach Tribes machst, solltest Du zunächst deine Wertschöpfungsstruktur und Customer Journey analysieren. Dann erst schauen, wie sich daraus sinnvolle Ordnungskriterien für deine Spotify Organisation ableiten lassen. So können z.B. Tribes nach Leistungsbereichen oder Produkten entstehen.
2. Wo entstehen die meisten Abhängigkeiten? Die schwierigste Arbeitsfrage bleibt sicher, wo in deiner Wertschöpfung die meisten Knotenpunkte und Abhängigkeiten entstehen. Diese zu identifizieren und dann zu versuchen, sie systematisch zu reduzieren, ist ein wichtiger Schritt auf dem Weg in deine agile Organisation.
3. Was ist der Purpose deines Unternehmens? Das Spotify Modell gibt jeder Tribe und jeder Squad maximale Autonomie. Das gelingt nur, wenn Ziele und Sinn deines Unternehmens greifbar und verständlich sind.
4. Abteilungsleiter sind nicht einfach die neuen Chapter Leads. Nur weil Du nicht weißt, wohin mit deinen jetzigen Führungskräften, macht es keinen Sinn, sie einfach zum Chapter Lead zu machen. In diesen Rollen brauchst Du Menschen, die Lust haben, andere zu befähigen, besser zu werden und sich zu entwickeln.
5. Wer begleitet den Change und die Einführung neuer Arbeitsweisen? Die Einführung des Spotify Modells ist nicht mit ein paar lustigen Postern und Powerpoints erledigt. Du brauchst eine Gruppe von agilen Coaches in deiner Organisation, die den Change begleiten und das Spotify Modell zum Leben erwecken.

Healthy culture heals broken processes.

Spotify Model

Das Spotify Modell ist ein tolles und gut zugängliches Beispiel für die Entwicklung einer agilen Organisation. Allerdings ist das Spotify Modell kein feststehendes agiles Framework, das Du blindlings auf deine Organisation übertragen kannst. Vielmehr findest Du im Spotify Modell eine gut dokumentierte Momentaufnahme und die Antwort einer Organisation auf ihre damaligen Herausforderungen. Und wenn Du deine Herausforderungen identifiziert hast, bei denen Agilität deiner Organisation helfen kann, dann findest Du im Spotify Modell eine Menge Inspiration für Eckpfeiler zu echter Business Agilität.

Viel Erfolg dabei.