Wie bereits im ersten Artikel angekündigt folgt nun der zweite Teil der Spotify Modell Reihe. Nachdem wir im ersten Teil die Namensgebung, sowie das Grundlagen Framework Scrum erörtert haben, handelt der zweite Teil vom Aufbau, den Rollen, sowie den Vor- & Nachteilen des Spotify Modells.
Das Spotify Modell – Aufbau
Innerhalb des Spotify Modells gibt es verschiedene Cluster bzw. Strukturen wie z.B. Squads, Tribes, Chapter und Gilden. Nachfolgend werden diese Gruppierungen anhand von Beispielen erklärt und abschließend mit einer Grafik veranschaulicht.
Squads
Squads sind die kleinste Einheit innerhalb des Spotify Modells. Ein Squad ist mit einem einzelnen Scrum Team vergleichbar. Innerhalb eines Squads arbeitet der Product Owner sehr eng mit dem Entwicklungsteam zusammen um die Produktentwicklung voranzutreiben. Der Fokus eines Squads bilden einzelne Funktionalitäten oder Bereiche des zu entwickelten Produkts oder Dienstleistung. Die Rolle des Scrum Masters gibt es innerhalb dieses Models nicht mehr, dafür wurde der Agile Coach auf Tribe-Ebene eingeführt, der mehrere Squads betreut. Diese Betreuung deckt alle Aufgaben des Scrum Masters und noch weitere Tätigkeiten mit ab.
Tribes
Mehrere Squads bilden ein Tribe. Dies bedeutet, dass es mehrere einzelne Teams, bestehend aus dem PO und dem Entwicklungsteam, gibt und durch den Agile Coach, der alle Squads innerhalb des Tribes betreut.
Die Tribes sollten sinnvollerweise so aufgebaut werden, dass logisch in sich geschlossene Produkteinheiten oder Dienstleistungsbereiche abgedeckt werden. Tribes arbeiten weitestgehend autonom im Vergleich zu anderen Tribes, was allerdings nicht bedeutet, dass die tribe-übergreifende Kommunikation nicht etabliert oder gepflegt werden soll. Auch hier ist es wichtig potentielle Hindernisse und Abhängigkeiten frühzeitig zu erkennen.
Chapter
Ein Chapter ist ein Zusammenschluss aus Fachkräften innerhalb derselben Profession oder mit denselben Interessen. Ein Chapter dehnt sich über mehrere Squads aus, bleibt aber innerhalb der Grenzen des Tribes angesiedelt.
Ziel von Chaptern ist es, dass sich die Fachkräfte regelmäßig über div. fachliche Themen austauschen, sowie sich gegenseitig helfen und schulen können. Jedes Chapter besitzt eine Person die das Chapter führt. Führen ist hier nicht im klassischen Sinn der Personalführung gemeint, sondern vielmehr ist diese Person für die Erstellung des Rahmens indem sich das Chapter bewegt verantwortlich. Dies beginnt z.B. bei der Serientermineinladung, Raumbuchung bis hin zur proaktiven Einladung von Experten zu Schulungszwecken.
Mögliche Beispiele für sinnvolle Chapter sind: Entwickler Chapter aufgeteilt in den Technologie Stack (z.B. Java, Python, JSON, usw.)
Gilden
Eine Gilde ist mit einem Chapter vergleichbar. Auch hier gibt es wieder einen Leader bzw. Koordinator der denselben Aufgaben nachgeht wie auch der Chapter Leader. Der Unterschied zwischen einem Chapter und einer Gilde besteht in der Rahmensetzung. Dies bedeutet, dass sich Gilden, im Gegensatz zu Chaptern, nicht auf einzelne Tribes beschränken, sondern die Mitarbeiter der gesamten Organisation mit einbindet.
Das Spotify Modell – Rollen innerhalb der Teams
Das Spotify Modell basiert auf dem agilen Scrum Framework. Deshalb ist es nicht verwunderlich, dass die ersten drei Rollen innerhalb des Spotify Modells sich mit denen des Scrum Frameworks decken. Darüber hinaus wurden jedoch noch vier weitere Rollen etabliert. Diese sind notwendig, da das Spotify Modell die Größe eines Scrums übersteigt.
Im nachfolgenden Abschnitt werden alle Rollen kurz angerissen, damit ein besseres Verständnis über die jeweiligen Verantwortlichkeiten, sowie die Einordnung innerhalb des Spotify Modells erlangt wird.
Der Product Owner
Der Product Owner bleibt in seiner Tätigkeit, im Vergleich zum Scrum Framework, unverändert. Dies bedeutet er ist für die Produktdefinition, die Abstimmung mit den Stakeholdern, die Verwaltung des Budgets, die Erstellung der Epics / User Stories und dem Backlog Management verantwortlich.
Der Product Owner ist Teil eines Squads, jedoch nicht dessen Leiter, da das gesamte Team sich selbst koordiniert.
Der Agile Coach
Im Rahmen von Scrum gibt es den so genannten Scrum Master. Die Rolle des Agile Coaches basiert auf der Scrum Master Rolle, wurde allerdings im Rahmen des Spotify Modells erweitert. Somit ist der Agile Coach nicht nur für die Einhaltung des Scrum Frameworks und die Beseitigung von Impediments verantwortlich, sondern soll die gesamte Organisation im Rahmen einer agilen Transformation unterstützen.
Diese Unterstützung liegt darin, dass er die Mitarbeiter in Bezug auf agile Vorgehensweisen schult und kontinuierlich analysiert, inwiefern eingesetzte Methodiken optimiert werden können, damit das gesamte Team noch performanter arbeitet.
Das Entwicklungsteam
Das Entwicklungsteam ist nicht eine dedizierte Rolle, sondern ein Konglomerat aus Mitarbeitern die benötigt werden um das Produkt bzw. die dafür verantwortliche Funktionalität fertigzustellen. Dies bedeutet, dass sich die Zusammensetzung der Squads, auch innerhalb eines einzelnen Tribes, stark an der benötigten Expertise orientiert und somit die Teamzusammensetzung beeinflusst. Die Gesamtteamgröße bleibt im Vergleich zum Scrum Framework ebenfalls unverändert und beträgt sechs bis neun Personen. Bei zu wenig Personen im Team ist die Wahrscheinlichkeit sehr hoch, dass zur Produkterstellung benötigte Fähigkeiten fehlen und bei einem Team größer als neun Personen der Koordinationsaufwand zu groß wird. Der Agile Coach, als auch der Product Owner sind von dieser Zählung nicht betroffen, außer wenn sie Aufgaben aus dem Product Backlog bearbeiten.
Klassische Rollen eines Entwicklerteams sind z.B. (Reihenfolge ohne Wertung):
- Frontend Entwickler
- Backend Entwickler
- UX-Designer
Der Tribe Leader
Jedes Tribe hat einen Tribe Leader der für Produktentwicklung des gesamten Tribes verantwortlich ist. Zu seinen Aufgaben zählen z.B. die Abstimmungen mit anderen Tribe Leadern um Abhängigkeiten und daraus mögliche Handlungsweisen zu identifizieren. Auch potentielle Hindernisse zwischen den Tribes sollen hier bereits identifiziert werden.
Der Chapter / Gilden Leader
Jedes Chapter und jede Gilde werden von einem sog. Chapter bzw. Gilden Leader geführt. Die Aufgabe des Chapter / Gilden Leaders ist es, dass sich die Mitglieder regelmäßig treffen und zu den von ihnen gewählten Themen austauschen. Innerhalb eines Chapters ist der Leader ebenfalls verantwortlich dafür, dass die Fachexperten das Wissen, das sie zur täglichen Arbeit benötigen, aufbauen können. Hierzu können chapter-interne Schulungen durchgeführt oder Gastredner eingeladen werden.
Der System Owner
Der System Owner trägt für das Gesamtsystem des Produkts die Verantwortung. Am Beispiel von Spotify gibt es z.B. pro Plattform auf der das Produkt verfügbar ist, einen System Owner. Dies bedeutet, dass es für die Mobile App für IOs, Android und dem PC Programm jeweils einen System Owner gibt. Je nach Produkt bzw. Produkttyp sind auch andere Gruppierungen gedanklich möglich.
Der Chief Architect
Der Chief Architect ist ebenfalls eine übergreifende Rolle innerhalb des Spotify Modells. Er ist für die Gesamtarchitektur vom Produkt verantwortlich und stellt sicher, dass diese immer auf dem neusten Stand ist und die verwendete Architektur den Produktanforderungen entspricht.
Das Spotify Modell – Vor- & Nachteile
In diesem Abschnitt sollen die potentiellen Vor-, als auch Nachteile erörtert werden.
Vorteile
Ein großer Vorteil des Spotify Modells liegt bereits in der Grundstruktur. Diese basiert auf dem Scrum Framework. Scrum ist im Jahr 1995 entstanden und gewinnt zunehmend an Popularität, so dass der Grundstein in vielen Organisationen bereits verankert ist. Ein weiterer Vorteil ist, dass das Spotify Modell, im Vergleich zu anderen skalierten agilen Ansätzen, simpel gehalten wurde. Es wurde lediglich um neue Rollen erweitert die zwingend notwendig sind. Auch die Zusammenstellung der Squads (“Scrum Teams”), Tribes (“Scrum of Scrums”), Chapters und Gilden ist logisch aufgebaut und leicht nachzuvollziehen. Die Skalierbarkeit erfolgt über die Anzahl der Tribes die passend auf die Produktwelt der Organisation zugeschnitten sind.
Nachteile
Auf der einen Seite kann man sagen, dass der Vorteil des Spotify Modells in der Klarheit und Einfachheit liegt. Auf der anderen Seite jedoch gibt das Spotify Modell keinerlei Hinweise wie mit Rahmenparametern innerhalb von Großunternehmen umgegangen werden soll. Dies bedeutet es gibt keine Ratschläge bzgl. der Vision, den Portfolioprozessen oder der Budgetverwaltung auf Unternehmensebene. Dies bedeutet für große Organisationen, dass diese ihre eigenen Prozesse analysieren und ggf. Änderungen vornehmen sollten, um auch diese Prozesse optimal an das Spotify Modell anzupassen.
Ein weiterer Nachteil ist, dass das Modell bereits über 10 Jahre alt ist und es zum aktuellen Zeitpunkt keinerlei Hinweise von der Firma Spotify gibt, inwiefern sie das Modell erweitert oder angepasst haben. Das hier skizzierte Modell ist immernoch die Grundfassung.
Fazit
Beim Spotify Modell handelt es sich um eine Anpassung bzw. Vorgehensweise von Scrum die für die schwedische Software Firma gut funktionierte und u.a. auch für den Erfolg des Produkts verantwortlich ist. Dies bedeutet nicht, dass eine exakte Kopie des Modells für alle Firmen aus allen Branchen gültig ist und zum Erfolg führt. Vielmehr handelt es sich meiner Meinung nach hierbei um einen Gedankenanstoß, wie man Scrum erweitern kann und ggf. auch für seine Organisation nutzen kann. Sollten z.B. darüber hinaus weitere Rollen oder Gruppierungen notwendig sein um erfolgreich zu werden, sollte man die Anpassung vornehmen und prüfen, ob sie zum gewünschten Ergebnis führt. Die Essenz aus diesem Modell ist die offene Fehlerkultur, sowie das kontinuierliche Lernen. Dies bedeutet, dass die gesamte Organisation regelmäßig überprüfen sollte, wo es potentielle Risiken, Hindernisse oder einfach noch Raum für Verbesserungen gibt und diese zielgerichtet und nachhaltig ändern und verbessern. Das Spotify Modell ist das Resultat dieser Arbeit.
Organisationen sollten auch nicht einfach ihre bestehenden Strukturen umbenennen, da dies keinen Mehrwert bietet. Organisationseinheiten müssen sinnvoll aufgeteilt und strukturiert sein, damit das Modell greifen kann. Dies ist von Organisation zu Organisation unterschiedlich, abhängig vom jeweiligen Produkt bzw. der angebotenen Dienstleistung.
Was sind Ihre Erfahrungen bezüglich des Spotify Modells? Haben Sie dieses bereits in der Praxis getestet?