Vor etwas mehr als 10 Jahren, als die allgemeine Skepsis gegenüber Spotify noch lauter war als die streambaren Songs, organisierte sich das Unternehmen durch Scrum. Aber je größer Spotify wurde und je mehr Scrum Teams es gab, desto öfter stießen die Teams an ihre Grenzen. Die Scrum-Praktiken passten nicht mehr und boten ihnen nicht die Lösungen für die Herausforderungen, vor denen sie standen. Da entschied sich Spotify, mit Scrum zu brechen und die Regeln für optional zu erklären. Sie besannen sich neu auf die agilen Prinzipien und begannen, ihren eigenen Weg zu suchen.
So organisierte sich Spotify neu
Die Scrum Teams wurden ermutigt, eigene Erfahrungen mit neuen Methoden oder Tools zu sammeln. Frei nach dem Motto: Wenn es hilft, ist es richtig. Mit folgendem Ergebnis: Aus den ehemaligen Scrum Teams wurden sogenannten Squads.
Squads?
Squads sind crossfunktionale, selbstorganisierte Teams von fünf bis neun Personen, die – ähnlich einem Scrum Team – gemeinsam die komplette Verantwortung aus allen nötigen Gewerken beinhalten um Produkte zu entwickeln.
Die Größe von Squads ist – genauso wie in agilen Teams – daher limitiert, da eine informelle Zusammenarbeit nur bis zu einer gewissen Größe gut funktioniert. Je größer eine Squad wird, desto mehr Kommunikationswege kommen hinzu und desto schwieriger wird es, dass das Team selbst schnell genug auf neue Erkenntnisse und Ereignisse reagieren kann.
Damit sich in jeder Squad ein Team-Sprit und eine gemeinsame Zielvorstellung entwickeln kann, empfiehlt es sich zudem, dass die Squadmitglieder langfristig Teil der Squad sind. Jede Squad entscheidet selbstständig, was entsteht, wie es entsteht und wie sie währenddessen zusammenarbeiten.
Die Rollen in Squads
Vergleichbar mit Scrum gibt es auch in Squads verschiedene Rollen mit verschiedenen Zuständigkeiten. So gibt es mit dem*der Product Owner*in eine Person mit Fokus auf das Produkt. Diese Person ist weder in die technische, noch die methodische Umsetzung involviert, sondern priorisiert die Anforderungen nach Wert für die Kund*innen. Sie stellt zudem sicher, dass das Team die Anforderungen verstanden hat.
Anders als der*die Product Owner*in ist die Rolle Agile Master*in nicht Teil einer Squad. Ähnlich wie ein*e Scrum Master*in, unterstützt ein*e Agile Master*in das Team dabei, die eigene Zusammenarbeit samt Arbeitsweisen zu verbessern.
Bei Bedarf und wenn die Einfachheit der Arbeit nicht gestört wird, können zudem weitere Rollen mit Spezialfokus hinzugefügt werden.
Auf dieser Grafik sind einige Squads zu erkennen. Alle Menschen, die vertikal übereinander abgebildet sind, ergeben eine Squad. Die braune Person ganz oben ist der*die jeweilige Product Owner*in.
Squads und Tribes
In der Grafik ist auch zu erkennen, dass sich mehrere Squads in sogenannten Tribes (also einen Stamm) zusammenfinden. Gemeinsam arbeiten die Squads eines Tribes an der Realisierung eines bestimmten Ziels. Jedes Tribe verfügt über eine*n Agile Master*in und eine*n Tribe Lead. Diese Person ist dafür zuständig, für die optimalen Rahmenbedingungen für die Squads zu sorgen.
Auch für Tribes gibt es eine Maximalgröße: 100 Personen. Diese Grenze gibt es, damit es möglich ist, dass sich alle untereinander auch tatsächlich kennen und eine Art Wir-Gefühl entstehen kann. Werden es mehr Menschen, würde die direkte Kommunikation relativ schnell Regeln der Zusammenarbeit weichen.
Chapters und Guilds
Innerhalb eines Tribes bilden die Menschen, die die gleiche Funktion in unterschiedlichen Squads haben, ein sogenanntes Chapter (auf der Grafik horizontal eingefärbt). Alle, die für das Marketing zuständig sind, bilden beispielsweise ein Marketing-Chapter. Während der Hauptfokus eines Squads auf der Produktentwicklung und der Qualitätssicherung liegt, bildet ein Chapter eine Art Kompetenzteam, eine Qualitäts-Assistenz. Das Chapter-System gewährleistet, dass thematisch auch über die Squads hinweg kommuniziert und koordiniert wird. So ist am Ende jede Person bei Spotify Teil eines Squads, eines Tribes und eines Chapters.
Jedes Chapter hat eine*n Chapter-Leader*in – die Führungskraft der jeweiligen Mitarbeiter*innen. Dieses System macht es für alle möglich innerhalb eines Tribes das Squad zu wechseln. Die Führungskraft bleibt identisch.
Und damit die Tribes nicht vollkommen losgelöst voneinander agieren, gibt es die sogenannten Guilds (Gilden). Sie agieren bei allen Punkten, die übergreifend Thema sind. In einer Gilde kann mitmachen, wer Expertise hat und an der Problemlösung teilhaben möchte. Jede*r kann einer Gilde nach eigenem Wunsch beitreten oder sie wieder verlassen.
Antriebskraft Autonomie
All das wird durch Autonomie gesteuert. Es gibt keine Hierarchie. Alle Teammitglieder sind gleichberechtigt. Das fußt auf folgender Annahme: Ein*e gute*r Mitarbeiter*in trifft in 70 % der Fälle dieselbe Entscheidung wie sein Chef. In 20 % fällt er*sie bessere Entscheidungen, weil er*sie von einer Sache mehr Ahnung hat. Und in 10 % liegt er*sie daneben. Und so ist es die Aufgabe der Führungskräfte zu kommunizieren, welche Probleme warum gelöst werden müssen und welche Mission Spotify warum hat. Die Mitglieder im Squad bestimmen dann, wie das Problem gelöst oder die Mission erreicht werden soll. Dabei arbeiten alle zusammen, um die beste Lösung zu finden.
Autonomie motiviert und motivierte Menschen leisten bessere Arbeit und erzielen dadurch bessere Ergebnisse für das Unternehmen. Und autonomes Handeln gibt Spotify die Möglichkeit, Entscheidungen besonders schnell treffen zu können. Mit minimalen Übergaben und Wartezeiten. Es gibt keine Abhängigkeiten und komplizierte Koordination, die schnellen Entscheidungen im Weg stehen würden.
Autonomie bedeutet auch, dass jede Squad eigenständig entscheidet, mit welchen agilen Methoden oder Tools sie arbeiten möchte. Die Squads sind also nicht standardisiert. Und wenn eine Squad einen für sie besonders guten Arbeitsweg gefunden hat, haben andere Squads die Möglichkeit, dieselbe Art und Weise auszuprobieren und zu entscheiden, ob diese auch etwas für sie wären. So können sich die Squads gegenseitig untereinander unterstützen, den besten Weg zu finden.
Fehlerfreundlichkeit führt zu Experimentierfreudigkeit
Wer schneller Fehler macht, kann auch schneller lernen und wer schneller lernen kann, kann sich schneller verbessern. Das ist Strategie von Spotify-Gründer Daniel Ek. Daher strebt Spotify ein fehlerfreundliches Milieu an. Anstatt zeitaufwendig alle Risiken im Voraus zu durchdenken, können die Squads einfach Dinge ausprobieren. Und da sich innerhalb einer Squad alle Entscheidungsgewalt befindet, können Fehler auch genauso schnell wieder behoben werden. Es geht also nicht darum, wessen Schuld oder Fehler das war, sondern um die Frage: Was haben wir daraus gelernt? Was werden wir jetzt ändern?
Diese Fehlerkultur ermöglicht es, experimentierfreudig zu werden und Experimentierfreudigkeit zu fördern. Um möglichst viele gute Ideen zu finden und auszuprobieren, können alle Mitarbeiter*innen 10 % ihrer Zeit (sogenannte Hack Time) damit verbringen, auszuprobieren, was auch immer sie wie auch immer und mit wem auch immer möchten. Das gibt allen die Möglichkeit, ohne irgendeine Vorgabe zu experimentieren.
Und in der Produktentwicklung führt der Gedanke zu dem Ablauf, ein Produkt erst einmal in einer Minimalversion (MVP) zuerst an wenigen Nutzer*innen zu testen und dann so lange zu optimieren, bis das Produkt für alle Nutzer*innen zugänglich gemacht werden kann. Anstatt sich also im Vorfeld entscheiden zu müssen, welche Variante sinnvoller ist, werden einfach alle Varianten ausprobiert, die Ergebnisse verglichen und sich dann für die tatsächlich beste Variante entschieden.
Das "Spotify Modell" - eine Vorlage für andere?
Die eben beschriebene Art und Weise, wie Spotify damals aufgebaut war und arbeitete, veröffentlichten Henrik Kniberg und Anders Ivarsson im Jahr 2012. Aus diesem Protokoll wurde für viele ein Modell, was sie zu adaptierten versuchten. Viele Firmen nahmen also die Strukturen des „Spotify Modells“ und führten sie bei sich selbst ein. Und nicht wenige Beratungsagenturen verkauften das „Spotify Modell“ als agiles Skalierungsmodell.
Wer jedoch in der Vorgehensweise von Spotify von vor 10 Jahren eine agile Methode sieht, hat den Kern der Agilität nicht verstanden.
Woher kommt die Kritik am „Spotify Modell“?
Denn Agilität bedeutet Anpassungsfähigkeit, stetiges Lernen und Adaptieren. Agilität verschwindet, wenn sich nichts mehr verändert und nichts mehr verbessert wird soll. Als Spotify vor 10 Jahren veröffentlichte, wie sie gut arbeiten können, war dies genau das: Eine individuelle Momentaufnahme und kein Modell, welches sich auf jedes Unternehmen anwenden lässt. Ein genauer Blick in die Veröffentlichung von Kniberg und Ivarsson bestätigt dies:
Disclaimer: Spotify is (like any good agile company) evolving fast. 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.
Henrik Kniberg und Anders Ivarsson
Kniberg und Ivarsson machten deutlich, dass sich die beschriebene Struktur – als das Dokument veröffentlicht wurde – ganz im agilen Sinne schon wieder geändert hatte. Es ging nie darum einen Struktur-Vorschlag für andere Unternehmen zu veröffentlichen. Das würde auch den eigenen Werten und Erfahrungen widersprechen. Denn jede Squad entscheidet für sich in jedem Moment neu, wie sie agiert. Warum sollte dann Spotify komplett artfremden Unternehmen sagen, wie diese sich generell organisieren sollten?
Und umgekehrt: Es gibt nach eigenen Angaben eindeutig keine unangetasteten, ewig geltenden Regeln oder fixen Strukturen bei Spotify. Warum sollte man als Unternehmen also aus einer Momentaufnahme eines agilen Unternehmens fixe Strukturen bestimmen und diese einführen? Ganz zu schweigen davon, dass diese Momentaufnahmen bereits 10 Jahre alt sind?
Gilt das "Spotify Modell" als gescheitert?
Agiles Lernen funktioniert individuell. Dass Teile der damaligen Vorgehensweise für exakt dieses Unternehmen mit exakt diesen Mitarbeiter*innen und exakt diesem Geschäftsmodell der Produktentwicklung funktioniert hat, bedeutet in erster Linie eben genau das. Und in zweiter auch.
Wer durch Spotify erfolgreich wird, wird dadurch erfolgreich, dass die Erfahrungen von Spotify mit in den eigenen Ansatz einfließen. Es geht also darum, voneinander zu lernen und darauf basierend eine eigene Vorgehensweise zu entwickeln, welche sich laufend weiterentwickelt.
Was es jedoch nicht gibt, ist das einfaches Konzept „Spotify Modell“, welches von Unternehmen einfach übernommen werden kann, ohne dass Agilität gelernt wird oder sich die Unternehmenskultur ändern muss.