tech11 Blog

Was ist das Spotify-Modell und was hat tech11 damit zu tun?

Spotify ist wahrscheinlich den meisten von uns ein Begriff, denn das Unternehmen ist einer der erfolgreichsten Musik-Streaming-Anbieter weltweit. Obwohl der Dienst bereits 2008 gestartet wurde ¹, war sein erstes wirklich erfolgreiches Jahr 2012, als er 20 Millionen aktive Nutzer erreichte ².

In diesem Jahr veröffentlichte Spotify auch das Whitepaper „Scaling Agile @ Spotify“ ³, in dem das sogenannte „Spotify-Modell“ erstmals der Welt vorgestellt wurde. In diesem Papier beschrieben die Autoren Henrik Kniberg und Anders Ivarsson, wie die Struktur des Unternehmens damals aussah und wie sie ihren eigenen Ansatz für agiles Arbeiten verfolgten.

Kurz gesagt, das Spotify-Modell ist eine Adaption einer Matrixorganisation, jedoch mit anderen, ausgefalleneren Bezeichnungen für Organisationseinheiten wie „Stämme“, „Trupps“ oder „Gilden“. Wenn Sie tiefer einsteigen wollen, ist das Spotify-Modell ein kompletter Ansatz für eine agile Arbeitsweise.

Squads sind als selbstorganisierende, vollständige Geschäftseinheiten gedacht, die sich mit einem einzigen langfristigen Ziel befassen, wie z. B. die Spotify-App oder der Media-Player in der Desktop-Version. Der Fokus innerhalb dieser Squads liegt darin, dass sie wie ein „Mini-Startup“ agieren sollen, das komplett vom Unternehmen abgekoppelt werden kann und daher alle Fähigkeiten benötigt, die ein Team braucht, um autark zu sein.

Die nächste große Geschäftseinheit des Modells sind die Chapters, die die Jobfamilien darstellen. Sie dienen dem technischen Austausch außerhalb der Teams. Wenn Entwickler X zum Beispiel ein Problem hat, das er gerade in seinem Squad behoben hat, könnte dasselbe Problem in einem anderen Squad auftreten. Mit der Chapter-Struktur könnte Entwickler X mit Entwickler Y in einer Sitzung zum Wissensaustausch sprechen, um seine Erfahrungen zu teilen.

Bleiben also noch die verbleibenden Organisationseinheiten, Stämme und Gilden. Grundsätzlich bündeln Stämme mehrere Trupps, die meist als ein Stamm pro Standort verwendet werden, z. B. der Stamm Stockholm, der Stamm Berlin, usw. Gilden hingegen vereinen Gleichgesinnte innerhalb des gesamten Unternehmens. Sie können stammesübergreifend existieren und zum Beispiel alle Entwickler, die mit Java arbeiten, miteinander verbinden.

Nachdem Sie nun ein wenig über das Spotify-Modell wissen, bleibt die Frage: Was hat tech11 damit zu tun? Die Antwort auf diese Frage ist natürlich, dass wir dieses Modell für unsere Zusammenarbeit bei tech11 nutzen, aber es steckt noch mehr dahinter. Lassen Sie uns also tiefer eintauchen!

¹ https://newsroom.spotify.com/company-info/

² https://soundiiz.com/blog/the-history-of-spotify/

³ https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Warum verwendet tech11 dieses Modell?

Um zu verstehen, warum tech11 dieses Modell verwendet, sollten wir einen Blick darauf werfen, wie die Voraussetzungen in unserem Unternehmen aussehen. Da tech11 eine Versicherungsplattform für Sachversicherungen anbietet, gibt es einige Kunden mit unterschiedlichen Anforderungen, wie unsere Plattform für ihre Zwecke funktionieren soll. Das bedeutet für uns, dass wir die Plattform in fast jedem Projekt anpassen müssen, mal mehr, mal weniger. Und das führt dazu, dass wir Teams brauchen, die mit den Anforderungen dieses speziellen Kunden bestens vertraut sind. Zusammenfassend lässt sich sagen, dass wir für jeden Kunden ein eigenes Projektteam haben, das sich ausschließlich um die Anpassung seiner Anforderungen kümmert.

Wenn Sie sich nun an das erinnern, was wir im ersten Abschnitt dieses Blogs besprochen haben, sehen Sie vielleicht eine Ähnlichkeit mit einer Organisationseinheit, die von Spotify verwendet wurde. Können Sie es erraten?

Natürlich, es ist wie ein Squad.

Durch den Einsatz eines Squads - also eines Teams, das über alle Mitarbeiter verfügt, um alle Kundenanforderungen zu erfüllen - können wir eine effiziente Arbeitsweise mit diesem Team etablieren, um die höchstmögliche Kundenzufriedenheit zu erreichen. Außerdem können die Squads im Sinne von Spotify selbst entscheiden, für welche agile Methode sie sich entscheiden wollen. Wir haben Squads, die nach Scrum arbeiten, wir haben Squads, die nach Kanban arbeiten, und wir haben Squads, die ein bisschen von beidem machen. So entsteht ein echtes agiles Umfeld, in dem wir die Teams befähigen, einen agilen Projektmanagementansatz zu verfolgen.

Darüber hinaus hat tech11 Kapitel eingeführt, die mit den Squads einhergehen. Ähnlich wie bei Spotify war es das Ziel, eine Heimat für alle Entwickler der gleichen Jobkategorie zu haben, z.B. das Backend Chapter. Bei tech11 bezeichnen wir sie mehr oder weniger als Job-Familien oder auch als Chapters.

Was wir bei tech11 nicht wirklich verwenden, sind Stämme, da wir die verschiedenen Standorte thematisch nicht voneinander trennen. Jemand aus Accra könnte mit jemandem aus Würzburg im selben Squad zusammenarbeiten. Gilden hingegen werden in offenen Teams verwendet, z.B. in unserem DevOps-Team, wo jeder mitmachen kann.

Das ist doch alles, oder? Nein, wie Apple haben wir noch eine Sache...

Mikro-Squads

• 1 Agile Coach
• 2 Business Analysten
• 2 Backend Entwickler
• 2 Frontend Entwickler
• 1 Tester
• 1 Technischer Redakteur

Wenn Sie sich näher mit dem Spotify-Modell befasst haben, ist Ihnen vielleicht aufgefallen, dass ein Product Owner in dieser Liste fehlt. Bei tech11 haben wir keinen einzelnen PO, der sich um alle unsere Backlogs kümmert. Stattdessen haben wir ein Plattform-Komitee, das vier Prioritäten setzt und diese dann an unsere sogenannten Story Owner weitergibt.

Diese Story Owner sind die funktionalen Manager der Micro Squads und sollen den anderen Kollegen im Team die Prioritäten vorgeben und sie anleiten. Typischerweise sind bei tech11 Business Analysten die Story Owner für die meisten unserer Micro Squads, aber wir hatten auch einige Entwickler, die diese Rolle erfolgreich übernommen haben.

Nachdem die Micro Squad die Entwicklung ihres Features abgeschlossen und unseren internen Review-Prozess bestanden hat, löst sich dieses Team auf und bildet eine neue Micro Squad, die normalerweise aus anderen Kombinationen von Teammitgliedern besteht.

Geschichte und Herausforderungen von Micro Squads

Sie können sich vorstellen, dass Micro Squads bis heute nicht nur Spaß und Erfolg gebracht haben. Natürlich gab es einige Schwierigkeiten und Herausforderungen, vor allem am Anfang. Wie bei jeder anderen Veränderung in der Welt waren die Menschen anfangs etwas skeptisch. Wir haben die Micro Squads im Juni 2023 eingeführt und sind ein paar Wochen später mit den ersten gestartet.

Häufige Probleme zu Beginn waren Serverprobleme bei der Einrichtung des speziellen Micro Squad-Entwicklungsservers. Anfangs wollten wir, dass unser Betriebsteam jeden Server einrichtet, aber wir merkten schnell, dass dies viel kostbare Zeit in Anspruch nehmen würde.

Außerdem waren die Micro Squads das erste Mal, dass neben den Delivery-Teams auch Mitarbeiter verschiedener Abteilungen funktionsübergreifend zusammenarbeiteten. Natürlich braucht man eine gewisse Zeit, um sich an die Arbeitsweise anderer zu gewöhnen, vor allem, wenn man die andere Person vorher vielleicht noch gar nicht kannte.

Ein dritter und wichtiger Aspekt waren unsere Schätzungen, wie lange diese Micro Squads dauern werden. Ursprünglich sollten die Micro Squads nicht länger als drei Wochen in Anspruch nehmen. Das ist ehrgeizig, aber wir wollten User Stories erstellen, die in dieser Zeit zu bewältigen sind. Was wir nicht bedacht hatten, war, dass unsere bestehenden Geschichten für diesen Ansatz noch nicht bereit waren. Einige sind bis heute noch nicht fertig. Das Ergebnis war, dass wir mit Micro Squads begannen, deren Fertigstellung Wochen, wenn nicht sogar Monate dauerte, während wir gleichzeitig darum kämpften, ein realistisches Fälligkeitsdatum für sie zu finden.

Glücklicherweise haben wir die meisten dieser Probleme überwunden. Die Probleme bei der Einrichtung des Servers wurden durch die Infrastruktur in Form von Code-Pipelines beseitigt, die mit einer netten Readme-Datei geliefert werden, so dass jeder in der Lage ist, den Server einzurichten, ohne dass das OPS-Team eingreifen muss. Nach einiger Zeit lernten sich mehr Leute kennen und mochten sich, so dass wir jetzt an einem Punkt sind, an dem die Teams manchmal für mehrere Micro Squads länger in einem Team bleiben wollen, anstatt sich aufzulösen. Außerdem sind wir jetzt an einem Punkt angelangt, an dem selbst gesetzte Termine realistischer sind und die Teams innerhalb der Micro Squads produktiver sind, so dass sie diese Rolle schließlich erfolgreich erfüllen können.

Nachdem das Micro Squad die Entwicklung seiner Funktion abgeschlossen und unseren internen Überprüfungsprozess bestanden hat, löst sich dieses Team auf und bildet ein neues Micro Squad, das in der Regel aus anderen Kombinationen von Teammitgliedern besteht.

Vorteile der Micro Squads (bis jetzt)

Da es nun fast ein Jahr her ist, dass unser erstes Micro Squad an den Start ging, können wir nun eine schöne Zusammenfassung der letzten 12 Monate ziehen. Die Micro Squads haben sich zu einem Punkt entwickelt, an dem wir sie wirklich als Effizienzsteigerung für unser Unternehmen bezeichnen können. Die Umstellung von unserem alten System auf die aktuelle Organisationsstruktur ging mit einer enormen Steigerung der Entwicklungsgeschwindigkeit einher.

Wenn wir ein durchschnittliches Ticket nehmen, an dem wir in der Vergangenheit gearbeitet haben, brauchten wir beispielsweise 9 Monate für Entwicklung und Tests. Das lag daran, dass jedes Team separat und nacheinander arbeitete, so dass die Wartezeiten einen großen Anteil an dieser langen Zeitspanne hatten.

Heute haben wir für die meisten Micro Squads Entwicklungszeiten von durchschnittlich 3-4 Wochen. Natürlich gibt es immer noch einige Ausreißer, aber das hängt dann eher mit dem Umfang der User Story zusammen und nicht mit Wartezeiten oder Problemen bei der Zusammenarbeit.

Wie bereits erwähnt, arbeiten unsere Mitarbeiter mit vielen anderen außerhalb ihrer Arbeitsgruppe zusammen und gewinnen dadurch viele neue Perspektiven und Erfahrungen. Das ist etwas, das oft in unseren Retrospektiven erwähnt wird. Generell haben wir den Micro Squads viele Befugnisse übertragen, und sie profitieren davon. Die Tatsache, dass unsere beste Erfolgsgeschichte eines Micro Squads mit einem Entwickler als Story Owner war, zeigt, wie sich jeder durch diese agile Arbeitsweise weiterentwickeln kann.

Etwas, das wir in der Zeit, in der die Micro Squads existierten, ebenfalls verbessert haben, ist die Qualitätssicherung hinter all diesen User Stories. Wir haben einen internen Überprüfungsprozess eingeführt, der mehrere Instanzen umfasst, um ein wirklich gutes Ergebnis zu erzielen.

Was ist die Zukunft des Spotify-Modells bei tech11?

Das ist wahrscheinlich die am schwierigsten zu beantwortende Frage in diesem ganzen Artikel. Da tech11 ein sehr agiles Unternehmen ist, stellen wir uns immer wieder die Frage „ist das noch der richtige Ansatz für uns?“. Ähnlich wie Kniberg & Ivarsson in ihrem Artikel „Scaling Agile @ Spotify“ schreiben, könnten sich die Dinge bereits geändert haben, wenn Sie dies lesen.

Aber eines ist sicher: Wir werden unsere Prozesse weiter verfeinern, neue Dinge ausprobieren und wenn sie sich bewähren, werden wir sie für alle Micro Squads implementieren. Und das Wichtigste ist, dass wir unseren Kollegen zuhören, was ihnen an den Prozessen gefällt, was ihnen nicht gefällt und was sie zur Verbesserung vorschlagen. Auf diese Weise versuchen wir, neue Wege der Zusammenarbeit zu finden und unseren Arbeitsalltag zu verbessern.