Das Squad-Teammodell von Spotify war ein Fehlschlag
(jeremiahlee.com)<p>"Spotify selbst nutzt 'das Spotify-Modell' nicht. Ihr solltet es auch nicht nutzen."<br />
Das 2012 bekannte Whitepaper von Spotify zu "Scaling Agile" war nur ihre Hoffnung und wurde nie vollständig umgesetzt.<br />
Das Whitepaper wich von der Realität ab, wurde aber beibehalten, weil es fürs Recruiting nützlich war; der Autor hat dies nach seinem Weggang dokumentiert, um das richtigzustellen.<br />
Ein detaillierter Artikel darüber, was an dem Modell falsch war, was man aus Spotifys Fehlern lernen kann und welche anderen Modelle empfohlen werden.<br />
<br />
Die Mitautoren des Whitepapers und die Agile Coaches bei Spotify haben Außenstehenden schon früher gesagt, dass man das nicht nachahmen solle.<br />
"Schon als wir das Whitepaper geschrieben haben, haben wir nicht so gearbeitet. Es war nur ein teilweiser Anspruch und eine Schätzung. Die Leute haben sich mühsam an etwas orientiert, das in Wirklichkeit gar nicht existierte."<br />
<br />
Warum hat es nicht gut funktioniert?<br />
<br />
1. Matrix-Management löst das falsche Problem<br />
<br />
Vollständig aufgestellte Agile-Teams funktionieren gut. Aber Matrix-Management schafft noch mehr Probleme.<br />
→ Spotifys Teams waren langfristig angelegt, daher war der Vorteil sehr begrenzt, dass man beim Wechsel in ein anderes Team nicht auch den Manager wechseln musste.<br />
→ Engineering Manager waren nur für das Niveau der Karriereentwicklung verantwortlich und konnten nicht dabei helfen, zwischenmenschliche Fähigkeiten und Ähnliches zu entwickeln.<br />
→ Es gab keinen einzelnen Manager, der für die Engineers eines Teams zuständig war. Dem Product Manager, der wie ein Mini-CEO fungierte, fehlte ein Gegenstück in einer Art Mini-CTO-Rolle. Es gab also niemanden, der Verantwortung für die Unterstützung des Technikteams trug oder Prioritäten verhandelte. Wenn es innerhalb des Technikteams Meinungsverschiedenheiten gab, musste der Product Manager mit allen Engineers verhandeln. Wenn das nicht reichte, wurde mindestens mit drei Backend-/Web-/Mobile-Engineering-Managern verhandelt oder bis zur technischen Leitung des Bereichs eskaliert.<br />
<br />
[ Was man aus Spotifys Fehlern lernen kann ]<br />
→ In Produkt-, Design- und Technikteams gibt es in der Regel mehr Engineers, daher sollte es einen Manager geben, der für alle Engineers verantwortlich ist, damit es bei Konflikten im Team einen Eskalationsweg gibt.<br />
→ Product Manager sollten für technische Themen einen gleichwertigen Peer haben, ähnlich wie CEO und CTO.<br />
<br />
2. Abhängigkeit von der Autonomie der Teams<br />
<br />
Solange ein Unternehmen klein ist, bearbeiten die einzelnen Teams ein breites Spektrum an Aufgaben, und oft wechselt auch, welches Team die Führung übernimmt.<br />
Wenn das Unternehmen wächst, werden doppelte Funktionen der Teams zur Effizienzsteigerung in neuen Teams zusammengeführt.<br />
Wenn es mehr Teams gibt, wechselt die Führungsrolle seltener, und die Teams können langfristig über die Probleme nachdenken, die sie lösen müssen.<br />
<br />
→ Spotify hat keinen gemeinsamen Prozess für die Zusammenarbeit zwischen Teams definiert. Jedes Team beteiligte sich auf seine eigene Weise, wodurch die Produktivität der Gesamtorganisation sank.<br />
→ Das "Spotify-Modell" wurde formuliert, als das Unternehmen noch deutlich kleiner war. Es hätte eine später aktualisierte Fassung geben müssen, doch dazu kam es nicht. Es blieb bei der Rede über Autonomie; der Teil zur Zusammenarbeit zwischen Teams wurde nie ausgearbeitet.<br />
<br />
[ Was man aus Spotifys Fehlern lernen kann ]<br />
→ Autonomie braucht Alignment. Die Unternehmensprioritäten müssen von der Geschäftsleitung festgelegt werden. Autonomie bedeutet nicht, dass Teams beliebig tun können, was sie wollen.<br />
→ Ein Prozess für teamübergreifende Zusammenarbeit ist zwingend nötig. Autonomie bedeutet nicht, jedes Team alle Probleme allein lösen zu lassen.<br />
→ Auch die Bewertung von Erfolg sollte von der Geschäftsleitung festgelegt werden, damit sich Prioritäten für teamübergreifende Zusammenarbeit abstimmen lassen.<br />
→ Autonomie verlangt Verantwortung. Product Management muss für den Produktwert verantwortlich sein. Jedes Team trägt die Verantwortung, ergänzte Teile auch wirklich „fertig“ zu machen. Reife Teams müssen ihre Unabhängigkeit dadurch rechtfertigen, dass sie geschäftlichen Wert, Risiken, Lernen und den besten nächsten Schritt sichtbar machen.<br />
<br />
"Wenn ich bei Spotify genau eine Sache hätte ändern wollen, dann dies: Wir hätten Autonomie nicht so stark betonen dürfen." – Joakim Sunden, ehemaliger Agile Coach bei Spotify<br />
<br />
3. Zusammenarbeit war nur eine vorausgesetzte Fähigkeit<br />
<br />
Spotify gab jedem Team Kontrolle über seine Arbeitsweise, aber viele Menschen hatten kein grundlegendes Verständnis von Agile.<br />
Dadurch mussten die Teams durch wiederholte Prozessanpassungen experimentieren, um eine Kombination zu finden, die ihren Output verbessert.<br />
Es gab keine gemeinsame Sprache, um Probleme im Prozess, Lösungswege oder die Bewertung von Ergebnissen effizient zu behandeln. In der Praxis war es nicht einmal Agile, sondern einfach nur "Not-Waterfall".<br />
<br />
Spotify hatte "Agile Coaches", die den Teams Prozessverbesserungen beibringen und empfehlen sollten. Die Absicht war gut, aber es gab nicht genug Coaches, um alle Teams zu unterstützen.<br />
Die Zeit, die jeder Coach einem Team zuweisen konnte, reichte nicht aus, um es bis zum Abschluss eines Projekts und zur Bewertung der Ergebnisse zu begleiten. Deshalb trugen sie letztlich für nichts Verantwortung.<br />
<br />
[ Was man aus Spotifys Fehlern lernen kann ]<br />
→ Zusammenarbeit ist eine Fähigkeit, die Wissen und Übung erfordert. Manager dürfen nicht davon ausgehen, dass Menschen bestehende Agile-Praktiken bereits verstehen.<br />
→ Wenn ein Unternehmen groß genug wird, braucht jedes Team eine Support-Organisation, die die Planung innerhalb des Teams und die Zusammenarbeit zwischen Teams ermöglicht. Program Management sollte für den Planungsprozess verantwortlich sein. Dedizierte Program Manager sollten dafür sorgen, dass Teams so arbeiten, dass Product Manager und Engineering Manager ihre jeweiligen Stärken einbringen und zugleich effektiv zusammenarbeiten.<br />
<br />
4. Mythen lassen sich schwer ändern<br />
<br />
Agile Scrum führte Begriffe wie Burndown und Sprint ein, weil neue Konzepte auch Namen brauchten.<br />
Spotify führte neue Begriffe wie Missions, Tribe, Squads und Chapter Lead ein. Das erzeugte die Illusion, man habe etwas geschaffen, das nur mit einer besonderen Wortwahl möglich sei.<br />
<br />
Entfernt man diese unnötigen Synonyme, ist das Spotify-Modell nur eine Sammlung von "Cross-Functional Teams" mit zu viel Autonomie und einer schwachen Managementstruktur.<br />
Hätte Spotify die Ideen dieses Modells mit ihren ursprünglichen Bezeichnungen benannt, hätte man das Scheitern des Modells vielleicht nicht als Veränderung kultureller Identität verstanden, sondern als Suche nach internen Prozessen, die besser funktionieren.<br />
<br />
[ Was man aus Spotifys Fehlern lernen kann ]<br />
→ Die meisten Unternehmen können nur wenige Innovationsbereiche dauerhaft tragen. Innovationen bei internen Prozessen sind nur selten das, was ein Unternehmen im Markt differenziert. Wer die Vergangenheit untersucht, kann bessere Bereiche finden, in denen Innovation sinnvoll ist.<br />
→ Optimiert auf Verständlichkeit. Um die Produktivität einer Organisation aufrechtzuerhalten, sollte man den Wert von allem bewerten, was Mitarbeitende neu lernen müssen.</p><p>*** Macht stattdessen Folgendes. ( Einen schnellen Weg gibt es natürlich nicht. )<br />
<br />
Wenn ihr nach dem Spotify-Modell gesucht habt, dann vermutlich, weil ihr eure Teamstruktur aufbauen wollt. Hört hier nicht auf, sondern recherchiert weiter.<br />
Unternehmen, die sich über einen längeren Zeitraum bewährt haben als Spotify, haben deutlich mehr darüber geschrieben.<br />
<br />
Spotify im Jahr 2012 fand keinen Weg, in einer großen Organisation die Geschwindigkeit und Agilität kleiner Teams aufrechtzuerhalten.<br />
Sie blickten über dieses frühe Modell hinaus nach außen, um bessere Antworten zu finden – und ihr solltet das ebenfalls tun.<br />
<br />
Empfehlungen des Autors für andere Arbeitsweisen<br />
<br />
- Habt ihr mehr als 200 Personen in eurer Produkt-, Entwicklungs- und Design-Organisation? Als ich bei Fitbit war, passte das "Scaled Agile Framework" gut.<br />
- Bei weniger als 200 Personen empfehle ich "Shape Up By Basecamp". Mein nächstes Startup werde ich mit einer solchen Struktur aufbauen.<br />
- Lest die Bücher "Essential Scrum" und "Team Topologies".</p>
4 Kommentare