Warum Dir das Spotify-Modell nicht wirklich weiterhilft

Das Spotify-Modell gilt vielen noch immer als Ansatz, mit dessen Hilfe es einer Organisation gelingen kann, agiler zu werden. Beispielsweise wurde es noch im letzten Jahr in einem Blogartikel auf Mooncamp neben Scrum, Kanban oder OKR als agile Methode genannt.

In diesem Beitrag zeige ich Dir, warum Du das Spotify-Modell (trotz gewisser Stärken) nicht einfach blindlings auf Deine Organisation übertragen kannst und es (höchstwahrscheinlich) mehr schaden als nutzen würde, wenn Du es anwendest. Denn auch wenn das Modell von Spotify auf den ersten Blick sinnvoll erscheint, besitzt es einige blinde Flecken.

Um diese blinden Flecken für Dich sichtbar zu machen, werde ich das Spotify-Modell deshalb am Ende dieses Beitrags mit den Team Topologies von Matthew Skelton und Manuel Pais vergleichen.

Bekannt wurde das Spotify-Modell durch eine zweiteilige Artikelserie von Henrik Kniberg aus dem Jahr 2014, in der er vieles über die Kultur beim Musikstreaming-Anbieter verriet. (Diese Beiträge sind mit sehr sehenswerten Videos versehen worden, von denen ich Dir hier eines verlinkt habe.)

Interessanterweise erlangte auch die Alignment-Autonomy-Matrix durch diesen Beitrag einige Berühmtheit.

Allerdings existiert neben diesen Blogartikeln auch noch eine PDF von Kniberg und Ivarsson, die ebenfalls die Zusammenarbeit bei Spotify thematisiert und bereits aus dem Jahr 2012 stammt.

Interessanterweise gibt es sowohl in der erwähnten PDF als auch in den Blogartikeln aus dem Jahr 2014 verschiedene Anmerkungen und Hinweise, dass es so etwas wie ein Spotify-Modell gar nicht gibt. Die Begeisterung, die dieses Modell bei vielen auslöste, führte jedoch dazu, dass diese Hinweise von Henrik Kniberg und Anders Ivarsson schlichtweg überlesen wurden und immer noch werden.

This article is only a snapshot of our current way of working -­ a journey in progress, not a journey completed. By the time you read this, things have already changed.

Selbst wenn Dir das Spotify-Modell also nachvollziehbar und sinnvoll erscheint, war es niemals als agiles Framework (für andere) gedacht. Es sollte lediglich zeigen, wie bei Spotify aktuell bzw. im Jahr 2012 gearbeitet wurde.

Bevor ich auf die Probleme und blinden Flecke des Spotify-Modells zu sprechen komme, möchte ich Dir das Modell selbst kurz vorstellen.

Das Spotify-Modell besteht aus vier unterschiedlichen Teamtypen, mit deren Hilfe die gesamte Softwareentwicklung strukturiert ist:

Squads bilden die kleinste Einheit des Spotify-Modells. Sie sind Scrum Teams sehr ähnlich, allerdings steht es ihnen frei, ihre Arbeitsweise selbst zu wählen. Deshalb kann sich hinter einem Squad auch ein Kanban Team verbergen oder auch ein Team, das Scrumban nutzt.

Darüber hinaus existiert für jedes Squad eine Mission bzw. ein klarer Verantwortungsbereich, wie beispielsweise „Den Androd Client verbessern“ oder „Das Backend-System skalieren“.

Mitglieder in einem Squad dürfen bzw. sollen außerdem ungefähr 10 % ihrer Arbeitszeit in sogenannte „Hack Days“ investieren, um Lernen & Innovation zu fördern.

Auf diese Weise fördert das Spotify-Modell auch organisationale Ambidextrie.

Mehrere Squads bilden im Spotify-Modell gemeinsam einen Tribe. Diese sind jedoch nicht willkürlich zusammengestellt, sondern bilden Themenbereiche, beispielsweise Backend-Infrastruktur oder Musik-Player.

Dabei orientiert sich das Spotify-Modell an der Dunbar-Zahl und sorgt dafür, dass ein Tribe nicht mehr also 100 Teammitglieder hat. Ein Teamlead sorgt dafür, dass alle Squads die bestmögliche Arbeitsumgebung haben. Dazu gehört zum Beispiel auch, dass alle Squads eines Tribes am gleichen Ort arbeiten. Physische Nähe innerhalb des Tribes ist also ein fester Bestandteil des Spotify-Modells.

Damit alle Squads und Tribes so unabhängig wie möglich arbeiten können, werden Abhängigkeiten zwischen ihnen regelmäßig besprochen und aufgelöst. Letzteres geschieht beispielsweise durch eine veränderte Backlogpriorisierung, Veränderungen an der Software-Architektur, neue Teamstrukturen oder auch technische Veränderungen.

Kniberg und Ivarsson gehen in ihrem Artikel jedoch nicht genauer darauf ein, wie, wie oft bzw. mit wem das genau geschieht. Zumindest merken sie an, dass kein regelmäßiges Scrum of Scrum stattfindet, weil es einfach nicht genügend Abhängigkeiten gibt, die dieses Meeting rechtfertigen würden. Vielmehr finden diese Meetings nur dann statt, wenn es notwendig ist.

Alle Teammitglieder eines Tribes, die sich mit den gleichen technischen oder fachlichen Themen beschäftigen, bilden gemeinsam ein Chapter. Sämtliche Software-Tester eines Tribes bilden beispielsweise ein Tester-Chapter. Alle Backend-Entwickler eines Tribes bilden ein Backend-Chapter und so fort.

Auf diese Weise ermöglicht das Spotify-Modell den gemeinsamen Austausch auf fachlicher Ebene, der durch interdisziplinäre Teams potenziell zu kurz kommt.

Chapters tragen außerdem dazu bei, gemeinsame Standards zu etablieren und zu erhalten.

Denn ohne die fachlichen Querverbindungen zwischen autonom arbeitenden Teams besteht eine hohe Chance, dass jedes Squad für bestimmte Probleme eigene Lösungen entwickelt. Das kann auf der einen Seite natürlich sinnvoll sein und Innovation fördern. Andererseits bieten bestimmte Standards, die in allen Teams gleichermaßen angewendet werden, durchaus Vorteile.

Neben Chapters existieren im Spotify-Modell sogenannte Guilds. Diese sind im Gegensatz zu Chapters nicht auf einen Tribe begrenzt und kommen der Idee einer Community of Practice sehr nahe. Beispiele für Gilden sind eine Agile Coach Guild, eine Tester Guild oder eine Webtechnology Guild.

Die Gilden des Spotify-Modells sind eine informelle Möglichkeit, gemeinsam zu lernen und Wissen zu teilen. Jeder Spotify-Mitarbeiter kann dabei jeder Gilde beitreten. Es gibt also keine Zugangsbeschränkungen oder dergleichen. Lediglich ein ausreichendes Interesse am inhaltlichen Thema der Gilde ist dabei wichtig.

Der wahrscheinlich größte Vorteil des Spotify-Modells ist sein Fokus auf Flow. Kleine, autonom und agil arbeitende Teams bietet die beste Möglichkeit, um Nutzen bzw. Wert für Kunden zu stiften.

Es ist eine Stärke des Spotify-Modells, dass es seine Squads zum Ausgangspunkt macht und mit Tribes, Chapters und Guilds Strukturen schafft, die die Arbeit in Squads bestmöglich fördern.

Die zweite große Stärke des Spotify-Modells ist, dass Squads (und Tribes) klar definierte Domänen haben. Dieses Vorgehen fördert Verantwortung und Ownership innerhalb der Teams. Viele Unternehmen und Organisationen leiden darunter, dass es für bestimmte Software-Module keine klar zugeordneten Teams gibt oder diese Verantwortung über mehrere Teams verteilt ist. Im Alltag werden gerade diese Software-Module stiefmütterlich behandelt oder werden komplett „übersehen“. Schlimmstenfalls gibt es dann keinen Ansprechpartner, wenn plötzlich Probleme auftauchen sollten.

Drittens fördert das Spotify-Modell gute Teamstrukturen und -interaktionen, weil die Zugehörigkeit zu einem Squad durch lokale Nähe unterstützt wird. Squads eines Tribes teilen sich eine gemeinsame Bürofläche und sind (wann immer möglich) nah zueinander platziert. Auf diese Weise ist auch der informelle, teamübergreifende Austausch möglich.

Auch die Chapters und Guilds des Spotify-Modells fördern den teamübergreifenden Austausch zwischen den einzelnen Squads. Sie leisten einen sehr guten Beitrag, um Innovation, gemeinsames Lernen und Austausch zu fördern.

Neben diesen Stärken hat das Spotify-Modell auch einige gravierende Schwächen, die es für die agile Skalierung ungeeignet machen. Diese Schwächen überwiegen meiner Ansicht nach die Vorteile des Spotify-Modells, sodass es unbrauchbar bzw. nicht einfach auf jede andere Organisation übertragen werden kann. (In der Hoffnung dadurch agiler zu werden.)

Die Schwächen des Spotify-Modells werden sichtbar, wenn wir es mit grundlegenden Prinzipien der Team Topologies vergleichen.

Das sind inbsesondere die Cognitive Load Theory, Conway’s Law und die in den Team Topologies verwendeten Interaktionsformen.

Zwar werden im Spotify-Modell für jedes Squad spezielle Domänen definiert, allerdings wird dabei kein Wort über den Cognitive Load verloren, den diese Domänen verursachen.

Zweitens verliert das Spotify-Modell kein Wort über die Zusammenhänge von Teamstrukturen und Software-Architektur. Der Team-Topologies-Ansatz hingegen legt einen starken Fokus auf diese Zusammenhänge. Matthew Skelton und Manuel Pais beziehen sich dabei auf Conway’s Law.

Im Endeffekt bedeutet das, dass die kopierten Teamstrukturen des Spotify-Modells die Architektur der daraus resultierenden Software verändern werden. Kopiert ein Unternehmen also das Spotify-Modell, verändert es nicht nur seine Teamstrukturen, sondern auch (langfristig) seine Software. Natürlich kann das einen positiven Effekt haben. Nämlich immer dann, wenn sich dadurch die Software-Architektur verbessert.

Umgekehrt ist es jedoch genauso gut möglich, dass die neu entstehende Software-Architektur mehr Nach- als Vorteile mit sich bringt und eigentlich eine völlig andere Software-Architektur notwendig wäre. In dem Fall ist jedoch auch eine dafür passende Teamstruktur notwendig.

Drittens geht das Spotify-Modell nicht auf die Interaktionsformen ein, welche Squads, Tribes und Chapters nutzen, um in der täglichen Arbeit miteinander zu kommunizieren.

Skelton und Pais hingegen bieten mit Team Topologies einen Ansatz, der es ermöglicht, diese zu visualisieren und vor allem zu definieren.

Das ist wichtig, weil auch die Kommunikation bzw. Interaktion zwischen Teams einen starken Einfluss auf die daraus resultierende Software hat.

Aus dem vorherigen Punkt leitet sich ein vierter Nachteil des Spotify-Modells ab. Denn wenn wir für unsere Teams die gewünschten und besten Interaktionsformen festgelegt haben, sind wir in der Lage, sie mit der tatsächlich stattfindenden Kommunikation zu vergleichen.

Wenn wir beispielsweise feststellen, dass vier Teams sehr häufig kollaborativ zusammenarbeiten, sie aber eigentlich die Interaktionsform X-as-a-Service nutzen sollten, wissen wir, dass es irgendwo ein Problem gibt. Beispielsweise kann es sein, dass die Domänen der Teams nicht klar genug definiert wurden. Eventuell kann es auch sein, dass einem (oder allen Teams) Know-how fehlt. In diesem Fall böte es sich an, dieses durch ein Enabling Team aufzubauen oder komplexe Elemente aus der Verantwortung der Teams herauszulösen und ein Complicated-Subsystem Team zu gründen.

Zusammenfassend lässt sich sagen, dass das Spotify-Modell durchaus positive Elemente beinhaltet. Die Verwendung von kleinen, agil arbeitenden Teams (Squads) oder die Vernetzung durch Communities of Practices (Guilds) zählen beispielsweise dazu.

Allerdings bleiben entscheidende Aspekte wie Cognitive Load, Conway’s Law sowie klare Interaktionsformen zwischen den Teams unberücksichtigt. Deshalb ist das Spotify-Modell lediglich ein Modell, das für Spotify im Jahr 2012 sinnvoll, gut und richtig war. Es ist jedoch kein Modell, das von anderen Organisationen einfach übertragen werden kann.