Das Spotify Modell
Diese zweigeteilte Beitragsserie geht um das sog. Spotify Modell. Im ersten Teil gehen wir kurz auf die Namensgebung, sowie das als Grundlage verwendete Scrum Framework ein. Der zweite Teil handelt vom konkreten Aufbau, den Rollen, sowie den Vor- und Nachteilen des Modells.
Was verbirgt sich hinter “Spotify”?
Spotify ist das Hauptprodukt der schwedischen Startup Firma Spotify Technologies S.A. Dabei handelt es sich um einen Musik Streamingdienst, der es den Kunden ermöglicht Musik, Podcasts oder Hörbücher auf den verschiedensten Geräten (wie z.B. PC / Smartphone / AV Receiver) abzuspielen bzw. zu hören. Das Produkt Spotify hat aktuell (Stand 2020) ca. 299 Millionen Nutzer aus 92 Ländern, wovon 138 Millionen Kunden ein Abonnement besitzen.
Die Grundfunktionen von Spotify, sowie alle Inhalte, sind für alle Nutzer kostenlos und werden durch Werbung für das Unternehmen finanziert. Sobald der Kunde sich für ein Premium Abo entscheidet, stehen ihm alle und somit auch die erweiterten Funktionen des Produkts zur Verfügung.
Das Spotify Modell – Definition
Der Name des Modells stammt von der Firma Spotify Technologies S.A. bzw. des Produkts Spotify. Dies liegt daran, dass das Produkt in einer angepassten Form des Scrum bzw. SAFe Frameworks entwickelt und released wurde. Darüber hinaus wurde auch das dafür verwendete Modell erstmalig von Spotify Technologies S.A. (nachfolgend “Spotify”) veröffentlicht. Beim Spotify Modell handelt es sich also um eine angepasste Form der oben genannten agilen Rahmenwerke. Das Besondere dabei ist, dass das Modell auch in größeren Organisationen zügig und erfolgreich umgesetzt werden kann, sofern die Grundvoraussetzungen dafür gegeben sind.
Das Scrum Framework
Bevor der Aufbau des Spotify Modells erklärt wird, gehen wir zunächst auf die wichtigsten Punkte des Scrum Frameworks ein, da dieses das Fundament für Spotify bildet. Dies soll dabei helfen ein besseres Verständnis für das Spotify Modell zu entwickeln. Eine vollständige Erklärung des Scrum Frameworks finden Sie im offiziellen Scrum Guide.
Rollen innerhalb von Scrum
Ein Scrum Team besteht aus dem Product Owner, dem Scrum Master und einem Entwicklungsteam von insgesamt sechs bis neun Personen. Das Scrum Team ist ein multidisziplinäres und autarkes Team ohne einen dedizierten Leiter.
Der Product Owner ist für die Produktvision und dessen fachliche Anforderungsbeschreibung verantwortlich. Durch die Priorisierung der User Stories im Product Backlog gibt er dem restlichen Team die richtige Richtung der Produktentwicklung vor und bespricht den Fortschritt mit allen relevanten Stakeholdern. Auch das Budgetmanagement fällt in den Aufgabenbereich des Product Owners.
Der Scrum Master besitzt innerhalb des Scrum Teams eine Beraterfunktion. Er wird auch als sog. Facilitator bezeichnet. Er plant und moderiert z.B. die Sprint Retrospektive, erkennt und beseitigt frühzeitig Hindernisse und beschützt das Team von äußeren Einflüssen, die sich negativ auf die Teameffektivität auswirken können. Darüber hinaus analysiert er kontinuierlich die Arbeitsweisen im Team und schlägt diesbezüglich Verbesserungen vor, die vom Team verprobt werden können. Sollten die Maßnahmen erfolgreich sein, so werden sie fortgeführt.
Das Entwicklungsteam ist eine multidisziplinäre Gruppe von Personen mit den, für die Produktumsetzung, benötigten Fachkenntnissen btw. Expertise. Dies sind im Bereich der Softwareentwicklung z.B. Frontend Entwickler, Backend Entwickler, Datenbank Spezialisten, UX-Designer und Testexperten.
Zeremonien innerhalb von Scrum
Innerhalb von Scrum gibt es verschiedene Meetings, die während einem Sprint durchgeführt werden. Diese Meetings werden im Rahmen von Scrum als “Zeremonien” bezeichnet. Die nachfolgende Tabelle gibt eine Übersicht über alle offiziellen Zeremonien, deren Beschreibung, Ziel und gewünschten Teilnehmerkreis.
| Name | Beschreibung | Ziel | Teilnehmer |
| Sprint | ein- bis vierwöchige Entwicklungsphase inkl. Durchführung der Scrum Zeremonien | Umsetzung der User Stories Weiterentwicklung des Produkts Durchführung der Scrum Zeremonien | Scrum Team |
| Sprint Planning 1 | Der PO stellt seinen Wunschscope für den nächsten Sprint vor und das gesamte Team schätzt die Komplexität der User Stories. | geschätzte User Stories (Komplexität) Sprintbacklog (Vorschlag) | Scrum Team |
| Sprint Planning 2 | Das Entwicklungsteam erstellt die Sub Tasks und führt die Zeitschätzung pro Sub Task durch. Im Anschluss gibt das Team einen Forecast ab, ob der gewünschte Scope im nächsten Scope machbar ist. Falls nicht erfolgt eine Abstimmung mit dem PO. | Sub Tasks pro User Story Zeitschätzung der Sub Tasks Teamforecast für den nächsten Sprint Sprintbacklog (geschätzt) | Entwicklerteam + ggf. Scrum Master |
| Daily Meeting | 15-minütiges tägliches Meeting um, die sich in der Umsetzung befindlichen User Stories, zu besprechen. | Transparenz über den Sprintverlauf Klärung möglicher offener Fragen bzgl. der Entwicklung Aufzeigen von Impediments | Entwicklerteam + Scrum Master, PO optional |
| Sprint Review | Inhaltlicher Review bzgl. des geleisteten Scopes des aktuellen Sprints. | Transparenz über die Erreichung des geforecasteten Ziels Inhaltliches Update für alle relevanten Stakeholder | Scrum Team + alle relevanten Stakeholder |
| Sprint Retrospektive | Reflexionsmeeting bezüglich der Zusammenarbeit innerhalb des Scrum Teams. | konkrete Action Items zur Arbeitsverbesserung innerhalb des Teams | Scrum Team |
Artefakte innerhalb von Scrum
Neben den Zeremonien, spricht man in Scrum auch von Artefakten. Artefakte sind Objekte bzw. Ergebnisse die während eines Sprints entstehen. Artefakte erhöhen im Rahmen des Scrum Frameworks die Transparenz über die geleistete und bevorstehende Arbeit.
Die nachfolgende Tabelle zeigt alle offiziellen Scrum Artefakte inklusive einer Kurzbeschreibung und deren Verantwortlichen.
| Name | Beschreibung | Verantwortlich |
| Product Backlog | Priorisierte Liste der Produktanforderungsbeschreibung in Form von Epics und User Stories. Das Product Backlog ist ein lebendes Artefakt. Dies bedeutet, dass es nie abgeschlossen ist, sofern das Produkt auf dem Markt ist, da das Produkt stetig erweitert bzw. Bug Fixes vorgenommen werden. | Product Owner |
| Sprint Backlog | Priorisierte Liste der Produktanforderungsbeschreibung in Form von Epics und User Stories für den jeweiligen Sprint. Das Sprint Backlog ist somit ein Auszug aus dem Product Backlog. | Scrum Team |
| Inkrement | Umgesetzte User Stories bzw. das konkret entwickelte Produkt / Dienstleistung. | Scrum Team |
Definition of Done | Pflichtkriterien zum Abschluss der User Stories. Die DOD schafft ein einheitliches Verständnis darüber, wann die Arbeit an der jeweiligen User Story erfolgreich abgeschlossen ist. Dies minimiert Missverständnisse und beugt potentiellen Schuldzuweisungen vor. | Scrum Team |
Ablauf eines Sprints
Zu Beginn eines jeden Sprints wird das Sprint Planning 1 und Sprint Planning 2 durchgeführt. Nachdem das Sprintbacklog aus dem Productbacklog heraus erstellt wurde und das Team einen Forecast zur Machbarkeit des Sprints abgegeben hat, wird der Sprint offiziell gestartet.
Ab sofort beginnt die tägliche Entwicklungsarbeit, sowie die Daily Meetings (“Dailies”). Der Sprint wird mit dem Sprint Review und der teaminternen Sprint Retrospektive abgeschlossen.
Im Anschluss wird der neue Sprint geplant und durchgeführt.
Bestenfalls findet während des aktuellen Sprints schon ein Backlog Refinement (Meeting zur iterativen Verfeinerung der User Stories mit dem gesamten Team) statt, so dass die zukünftigen Sprints parallel zur Sprintdurchführung grob skizziert und erste Fragen geklärt werden können.
Eine ausführlichere Beschreibung des Scrum Frameworks wird innerhalb des offiziellen Scrum Guides beschrieben.
Der zweite Teil der Beitragsserie wird in ca. einer Woche in der Rubrik Neuigkeiten erscheinen.