Warum Spotifys Gruppen- und Stammesmodell wahrscheinlich nicht für Sie funktionieren wird

Was sind die selbst eingestandenen Probleme von Spotify mit diesem Modell?

Dieses Modell ist keineswegs ein Allheilmittel. Die Mitarbeiter von Spotify haben in vielen Beiträgen die Unzulänglichkeiten ihres Modells erläutert, und es scheint, dass die Realität nicht mit dem Mythos vom agilen Nirwana Schritt gehalten hat.

„Es beunruhigt mich, wenn Leute sich ansehen, was wir tun, und denken, es sei ein Rahmen, den sie einfach kopieren und implementieren können. … Wir bemühen uns jetzt wirklich sehr, zu betonen, dass wir auch Probleme haben. Es ist nicht alles ‚glänzend und alles funktioniert gut und alle unsere Teams sind super toll‘.“

Anders Ivarsson, Mitverfasser des Spotify-Whitepapers

Problem 1: Ingenieurskultur ist keine Organisationsstruktur

Der ursprüngliche Inhalt, den Spotify zur Erläuterung seiner Methode veröffentlichte, hieß Spotify Engineering Culture. Obwohl sie eine Organisationsstruktur skizzierten, ging es in erster Linie um ihre Ingenieurskultur und ihre zentralen Arbeitsprinzipien (siehe unten für eine Liste dieser Prinzipien).

Problem 2: Das Modell war ehrgeizig und wurde nicht vollständig übernommen

Als Spotify sein White Paper veröffentlichte, war es teils ehrgeizig und teils Realität. Sie stellten eine Vision für die Zukunft vor.

„Selbst zu der Zeit, als wir es geschrieben haben, haben wir es noch nicht umgesetzt. Es war teils ambitioniert, teils eine Annäherung. Die Leute haben sich wirklich schwer damit getan, etwas zu kopieren, das nicht wirklich existierte.“

Joakim Sundén, Agile Coach bei Spotify 2011-2017

Issue 3: Das Modell wurde für vollständige Teamautonomie optimiert

Als die Größe der Teams wuchs, hat Spotify keinen gemeinsamen Prozess für die teamübergreifende Zusammenarbeit definiert. Wenn jedes Team seine eigene Arbeitsweise hatte und es keine Richtlinien für die Auswahl gab, litt die Produktivität der gesamten Organisation.

Problem 4: Die Zusammenarbeit zwischen den Teams war eine vorausgesetzte Kompetenz

Als die Zahl der Teams wuchs, wurde erkannt, dass eine spezielle Unterstützung zur Steuerung und Strukturierung der Zusammenarbeit zwischen den Teams erforderlich war. Dedizierte Strukturen oder Prozesse sind erforderlich, damit Teams, die nicht unbedingt miteinander verbunden sind, zusammenarbeiten können.

„In Artikeln oder Vorträgen wie diesem kann der Eindruck entstehen, dass Spotify eine Art agiles Nirwana ist, in dem einfach alles funktioniert, und das ist einfach nicht wahr.“

Henrik Kniberg, Schöpfer des Spotify-Modells

Erinnern Sie sich daran, dass das Spotify-Modell vor mehr als 10 Jahren entwickelt wurde, so dass es sehr unwahrscheinlich ist, dass es angesichts der oben genannten und vielleicht auch anderer Probleme genau das Modell ist, das sie jetzt verwenden. Spotify ist ein Unternehmen, das ständig lernt und wächst, so dass es dieses Modell seit dem ursprünglichen Whitepaper mehrfach weiterentwickelt haben wird. Dennoch können wir viel daraus lernen, auch wenn Sie das Modell nicht direkt anwenden sollten.

Die Stärke des Spotify-Modells liegt eher in seinen technischen Prinzipien als in seinem Organisationsdesign

Die wahre Magie des Spotify-Modells lag in der Technik- und Produktentwicklungskultur, die sie für schnelle, motivierte, entkoppelte agile Teams geschaffen haben. Im Laufe der Zeit entwickelten sie einige starke Arbeitsgrundsätze, die ihre hohe Leistung untermauerten:

1. Produktivität ist eng mit Motivation verbunden – Motivation hat einen größeren Einfluss auf die Produktivität als jeder andere Faktor (siehe Richard Sheridans Joy Inc). Spotify verwendet die Formel Produktivität = Aufwand x Kompetenz x Umfeld x Motivation.
2. Gleichgewicht zwischen Ausrichtung und Autonomie – Spotify strebt ein Gleichgewicht zwischen Ausrichtung (zentrale Leitung) und Autonomie (Selbstorganisation des Teams) an. Die Manager zeichnen das große Bild, sagen den Leuten aber nicht, wie sie dorthin kommen oder wie sie die Probleme lösen sollen.
3. Entkoppelte Releases zur Verkürzung der Zykluszeit – Spotify hat seine Architektur geändert, um Abhängigkeiten zu entkoppeln und Releases einfacher und schneller zu machen. Dies ermöglichte häufigere Produktionsreleases, die teamübergreifend unabhängig sein können.
4. Vertrauen Sie Ihren Mitarbeitern – Spotify vertraut seinen Mitarbeitern und unterstützt sie, ohne zu versuchen, sie zu kontrollieren, weil sie glauben, dass die meisten Mitarbeiter das tun, was für das Unternehmen am besten ist.
5. Manager als dienende Führer – Es ist besser für Manager, die Teams zu fragen, wie sie helfen können, als die Leute zu fragen, woran sie arbeiten oder wann sie fertig sein werden.
6. Wertmaximierung statt Geschäftigkeit – Teams entwickeln Ideen, führen schnelle Experimente durch und messen dann die Ergebnisse. Auf dieser Grundlage passen sie ihre Vorgehensweise an, um den Wert zu maximieren.
7. Verbesserungskultur – Die Teams werden ermutigt, ihre Arbeitsweise zu verbessern, und haben ein Modell dafür, was ihr Leben einfacher und besser machen würde. Es stehen spezielle Ressourcen zur Verfügung, um die Arbeitsweise im gesamten Unternehmen zu verbessern.
8. Gesunde Kultur heilt kaputte Prozesse – Prozesse können oft kaputt gehen, aber eine gesunde Kultur führt dazu, dass die Menschen diese Probleme selbst beheben.
9. Teamdefinition von „awesome“ – Spotify ermutigt die Teams, darüber zu sprechen und zu entscheiden, was sie „awesome“ machen würde. Denn ohne eine Vision für das Großartige ist es unwahrscheinlich, dass man es erreicht. Spotify-Teams führen regelmäßig „Team Health Checks“ durch und verfolgen Verbesserungen im Laufe der Zeit. F: Haben Ihre Teams eine Definition von „fantastisch“? Verfolgen Sie den Gesundheitszustand des Teams und streben Sie nach kontinuierlicher Verbesserung?
10. Mitarbeiterzufriedenheit ist von größter Bedeutung – Spotifys Head of People behauptete, dass 91 % der Mitarbeiter gerne bei Spotify arbeiten, was er als „natürlich nicht zufriedenstellend“ bezeichnete… so hoch ist die Messlatte, die sie für sich selbst gesetzt haben.
11. Fehler sind in Ordnung – Spotifys CEO erklärt, dass Fehler erwartet werden, wenn man Innovationen vorantreibt. Um dies abzumildern, hat Spotify viele Systeme eingebaut, um die Auswirkungen von Fehlern zu begrenzen.

„Unser Ziel ist es, Fehler schneller zu machen als alle anderen“.

Daniel Ek, Gründer von Spotify

Wie man sieht, sind in das Modell einige großartige Konzepte eingebaut, aber es ist keine Blaupause für agile Organisationsgestaltung an sich.

Iterieren Sie mit inspect und passen Sie es an, um Ihr eigenes Zielmodell zu erstellen

Der Kontext Ihrer Organisation, Ihre Ausgangssituation, Ihre Kultur, Ihre Ziele und viele andere Faktoren werden die beste Lösung für Sie bestimmen.

Natürlich können Sie recherchieren und Ideen von Unternehmen wie Spotify, Menlo Innovations, Google oder anderen leistungsstarken Unternehmen übernehmen, aber das sollte nur der Ausgangspunkt sein.

Sie müssen genau wissen, welches Problem Sie zu lösen versuchen, und dann einen Plan erstellen, der auf der Lösung Ihrer einzigartigen Herausforderungen basiert.

Inspektieren und Anpassen ist ein Kernkonzept von Agile.

Inspektieren bedeutet, mit offenem Geist und transparentem Feedback (meist im Rahmen einer Retrospektive) ehrlich zu prüfen, was funktioniert und was nicht. Dabei kann es sich um Prozesse, Teamdynamik, Strategien oder Ineffizienzen handeln, also um alles, was die Teamleistung behindert und die Motivation und Eigenverantwortung des Teams mindert.

Anpassen ist der Prozess, bei dem die Themen aus der Selbstbeobachtung aufgegriffen und Wege gefunden werden, um darauf zu reagieren und sie zu verbessern. Die Anpassung erfordert Kreativität und Anstrengung und hat oft die Form eines Experiments. Ein kleiner Test wird mit einer Teilmenge der Teams durchgeführt, um sicherzustellen, dass die Lösung praktikabel ist, bevor sie in der gesamten Organisation eingeführt wird.

Dieser Prozess wird dann jedes Mal wiederholt, wenn die Organisation verbessert wird und sich ihrem idealen Zielzustand nähert.

Lassen Sie sich inspirieren, aber kopieren Sie nicht blind

Das Modell von Spotify hat viel zu bieten, wenn Sie die technischen Prinzipien übernehmen und den Geist des Unternehmens nachahmen.

Kontext ist alles, und wenn Sie nicht gerade ein schwedisches Musikstreaming-Unternehmen sind, wird das blinde Kopieren von Spotify Ihre Probleme wahrscheinlich nicht lösen.

Es ist jedoch sehr unwahrscheinlich, dass das blinde Kopieren des Modells für Sie funktioniert. Es ist wichtig, sich von verschiedenen Quellen inspirieren zu lassen, wenn Sie in Ihrem Unternehmen agil skalieren wollen.

Wenn Sie agil skalieren wollen und mehr als 150 Personen in Ihrem Team haben, dann sind zwei gute Skalierungsmodelle:

1. Scaled Agile Framework (SAFe)
2. Large Scale Scrum (LeSS)

Wenn Sie weniger als 150 Personen haben, ist Shape Up von Basecamp ein großartiges Modell, das Sie anstreben sollten.

Spotify ist kein agiles Nirwana

Ich hoffe, dieser Artikel hat deutlich gemacht, dass die agile Entwicklungskultur bei Spotify viel mehr ist als nur die Bildung von Squads, Chaptern, Stämmen und Gilden.

Das Spotify-Modell besteht vor allem aus der Kultur und den hochkompetenten Teams, nicht aus dem organisatorischen Aufbau. Auch ohne die Einführung von Squads und Stämmen kann man durch die Übernahme der Grundsätze große Vorteile erzielen.

„In Artikeln oder Vorträgen wie diesem kann der Eindruck entstehen, dass Spotify eine Art agiles Nirwana ist, in dem einfach alles funktioniert, und das ist einfach nicht wahr.“

Henrik Kniberg

Die Kurzversion der Skalierung von Agilität

Ich werde in Zukunft einen ganzen Blogbeitrag darüber schreiben, aber hier ist erst einmal die Kurzversion, wie Sie bei der Skalierung von Agilität in Ihrer Organisation vorgehen sollten:

1. Machen Sie sich klar, welches Problem Sie zu lösen versuchen.
2. Übernehmen Sie die besten und relevantesten Teile der besten Skalierungsmodelle der Industrie, z.B. SAFe, LeSS, DaD etc. in Ihr Zieldesign.
3. Entwerfen Sie einen Zielzustand, der die besten Praktiken für Ihre einzigartigen Herausforderungen nutzt.
4. Verändern Sie Ihr Zieldesign.
5. Inspect and adapt constantly to find improvements based on evidence.
6. Make course corrections based on the feedback.
7. Rinse and repeat steps 4 to 6!