Scaling Agile & Lean – Spotify Squads, Tribes and Chapters

Die Reihe „Scaling Agile & Lean“

Agile Methoden wie Scrum werden mittlerweile in den meisten Unternehmen eingesetzt, einige Studien gehen davon aus, dass 80% aller Unternehmen agile Prozesse einsetzen, konservativere Studien sprechen von etwas mehr als der Hälfte. In den meisten Fällen dürfte sich dies jedoch weiterhin auf den Einsatz von Scrum oder Kanban in Teilbereichen der Unternehmen, wenigen Teams oder Projekten beschränken.

Ansätze, um hinweg über viele Teams zu skalieren (Scaling Agile) fehlen häufig und werden für größere Unternehmen die auf Agilität setzen möchten immer wichtiger. Häufig scheitern Implementierungen von Scrum jedoch an dem fehlenden übergeordneten Koordinierungsbedarf, da der Fokus in den meisten Fällen zu sehr auf die Entwicklungs-Teams und weniger auf die Unternehmens- oder Portfolioebene gelegt wird. Besonder viele Reibungsverluste gibt es bei der Integration von agilen Organisationsteilen (z.B.: Entwicklung von neuen Systemen) und weiterhin eher traditionell organisierten Organisationsteilen (z.B.: Vertriebsorganisation, Abteilungen mit Fokus auf Wartung, Zulieferer).

Die Fragestellung, wie agile Methoden in größeren Unternehmen eingesetzt werden können, ist jedoch nicht neu. In der Reihe „Scaling Agile & Lean“ stellen wir einige der bekanntesten Frameworks und Methoden die hierbei Anwendung finden vor.

Scaled Agile @ Spotify im Detail

Einen sehr interessanten Ansatz für die Skalierung von agilen Teams verfolgt Spotify. Hier wurde auf über 30 Teams („Squads“) skaliert. Teams die in einem Kontext arbeiten, werden in sogenannten „Tribes“ gruppiert.  Der Kontextübergreifende Austausch geschieht durch die Etablierung von so genannten “Chapters”.

Diese Begrifflichkeiten mögen für einige gewöhnungsbedürftig sein aber sind sicherlich für viele Agilisten attraktiv, da diese häufig den klassischen Methodenwerken schon alleine wegen der vielfach missbrauchten Begrifflichkeiten ablehnend gegenüber stehen.

Liefereinheiten

Squad

Entspricht in etwa den üblichen agilen Teams, wobei kein spezifisches Vorgehen oder Framework wie beispielsweise Scrum oder Kanban vorgeschrieben ist. Es gibt einen Product Owner, der die Themen vorgibt und jemanden, der sich um das Team und die Einhaltung von Regeln kümmert (“Agile Coach”). Der “Agile Coach” gehört nicht ausschließlich zu einem Squad er muss aber für „seine“ Mitarbeiter verfügbar sein.

Scaling Agile @ Spotify
Scaling Agile @ Spotify

Ziel ist es, Squads so zu definieren, dass ein Squad für ein Teil des Produktes voll verantwortlich ist und selbstständig neues Features implementieren kann. Dies erfordert stabile Teams, die auch längerfristig Verantwortung übernehmen können, und eine gute Zusammenarbeit und Kommunikation zwischen verschiedenen Squads eines Tribes. Hierfür wird die entsprechende Umgebung bereitgestellt (Räume, Whiteboards) was den Abstimmungsaufwand reduziert. Die Squads haben größtmögliche Entscheidungsfreiheit, um ohne erhöhten Kommunikationsaufwand zu übergeordneten Stellen schnell Lösungen finden und Entscheidungen treffen zu können.

Because each squad sticks with one mission and one part of the product for a long time, they can really become experts in that area – for example what it means to build an awesome radio experience.

Um den Austausch und die Kommunikation zwischen den Squads und Tribes zu fördern, sowie kontinuierliche Verbesserung zu erlauben, werden ca. 10% der Zeit in gemeinsame Innovation investiert (“Hack Days”).

Tribe

Squads die im gleichen Kontext (z.B. “Music Player” oder “Backend Infrastructure”) arbeiten werden in einem so genannten “Tribe” gebündelt, wobei auf die “Dunbar’s Number” geachtet wird: Kein Tribe hat viel mehr als 100 Mitgliedern, da sonst die Kommunikation und Abstimmung leidet. Jede dieser Gruppen hat einen “Tribe Leader”, der dafür verantwortlich ist, dass die zugehörigen Squads optimal arbeiten können. Regelmäßig werden Meetings auf der Tribe-Ebene abgehalten. Diese dienen zum Informationsaustausch und bei Bedarf zur übergreifenden Planung. Zudem wird der aktuelle Stand der Produkte präsentiert und die Zugehörigkeit zum Tribe gestärkt.

In anderen Ansätzen wie dem Scaled Agile Framework wäre ein Tribe vergleichbar mit dem Agile Release Train und die Abstimmungsmeetings mit dem Release Planning Meeting auf Programm-Ebene. Detailliert wird auf diese Konzepte im Artikel über das Scaled Agile Framework eingegangen.

Abhängigkeiten und Abstimmung

Handhabung von Abhängigkeiten

Abhängigkeiten zwischen Squads werden transparent gemacht und aktiv adressiert (Organisation, Architektur, Fokussierung). Ziel ist es die Anzahl der Abhängigkeiten bzw. deren Auswirkungen (Verzögerungen, Risiken, Transaktionskosten) zu minimieren. Abhängigkeiten zwischen Squads führen dazu, dass Entscheidungen nicht mehr in der kleinen Gruppe getroffen werden, sondern Abstimmungsaufwand mit anderen Squads anfällt.

Dies wird noch arbeits- und zeitintensiver, sobald Abhängigkeiten zu anderen Tribes besteht. Abstimmungsaufwände zwischen den Tribes verlängern nicht nur die Durchlaufzeiten einzelner Features und erhöhen damit das Risiko Produktauslieferungen zu verzögern, sondern steigern auch den Kommunikationsaufwand und hierdurch die Komplexität zwischen den Tribes. Aus diesem Grund wird alles dafür getan diese Abhängigkeiten zu eliminieren.

Abstimmung und Ausrichtung

Die Schattenseite autonomer Teams ist eine höhere Entropie (mehr Unterschiedlichkeit / Abweichungen), schnell kann das übergeordnete Ziel zu Gunsten lokaler Optimierung aus den Augen verloren gehen. Um Skaleneffekte realisieren zu können und ein ausreichende Ausrichtung auf gemeinsame Ziele nicht aus den Augen zu verlieren findet eine übergreifende Abstimmung in so genannten Chapters und Guilds statt, die den Communities of Practice aus anderen Modellen entsprechen..

If each squad was fully autonomous and had no communication with other squads, then what is the point of having a company?

Chapter

Personen mit ähnlichen Skills aus dem gleichen Tribe treffen sich und tauschen sich aus. So gibt es Chapter für “Web Development” oder “Testing” in denen grundlegende Themen diskutiert werden und eine Abstimmung hinsichtlich Standards und eingesetzten Frameworks stattfindet.

Guild

Eine Guild ist eine Gruppe, die sich über Grenzen von einzelnen Tribes bildet, um Wissen auszutauschen, Werkzeuge und Herangehensweisen anzugleichen und Praktiken einzuüben.

System Owner & Chief Architect

Bei autonomen Squads die im Grunde überall im System Änderungen durchführen dürfen, besteht ein Risiko, dass die Architektur des Systems leidet. Aus diesem Grund gibt es einen “System Owner”, der eine Beratungsinstanz bei architektonischen Änderungen darstellt. Da Squads trotzdem selbst entscheiden dürfen, stellt der System Owner kein Bottleneck dar – allerdings stimmen sich die Squads ganz bewusst mit ihm ab, um Risiken zu reduzieren.

Tiefgreifende architektonische Änderungen und Neuentwicklung ganzer Systeme werden durch einen Chief Architect überprüft. Wobei auch der Chief Architect lediglich beratend tätig ist – die finale Entscheidung liegt bei den Squads, da diese auch die Konsequenzen tragen müssen.

Kultur

Bei Spotify hat Transparenz als agiler Wert eine große Bedeutung und wird im Unternehmen gelebt. Dies geschieht unter anderem mit dem regelmäßig ermittelten „Happyness-Index“. Hierbei werden die Mitarbeiter der einzelnen Squads anonym befragt wie zufrieden / glücklich sie mit ihrem ProductOwner, ihrem Agile Coach, Operations udgl. sind.

Wichtiger als die Momentaufnahme ist bei dieser Erhebung aber die Rückmeldung, ob sich im Zeitverlauf Verbesserungen oder Verschlechterungen ergeben haben. So kann ein Teammitglied beispielsweise seinen Product Owner nur durchschnittlich bewerten aber auch darauf hinweisen, dass die Performance sich weiter verbessert.

Mittels einer solchen Metrik kann nicht nur der Ist-Stand einer Änderung (z.B. Schulung,…) gemessen werden, sondern auch ob sich kleine Änderungen abzeichnen. Ähnlich kann man einen negativ-Trend auch schon als Frühindikator verwenden, um schnell und pragmatisch gegenzusteuern.

Im Gegensatz zum SAFe hebt der der Ansatz bei Spotify kulturelle Aspekte sehr stark hervor und vermeidet die Nutzung etablierter Begrifflichkeiten: Grundlegende Konzepte aus der Matrix-Organisation werden “trendig verpackt” und durch eine Spotify-eigene Terminology ersetzt. Bewusst werden Entscheidungsbefugnisse sehr stark auf die operative “Squad-Ebene” verschoben, wodurch wiederum die Identifikation mit dem (Teil-) Produkt und die Fokussierung auf eine schnelle Auslieferung zunimmt.

Quellen

Update

Ein gutes Video welches das Skalierungsmodell von Spotify anschaulich erläutert:

Spotify Engineering Culture – part 1 from Spotify Training & Development on Vimeo.

0 Gedanken zu „Scaling Agile & Lean – Spotify Squads, Tribes and Chapters

  1. Pingback: Betriebssystem Responsive OS 4.0 (4/n) | FLOWCAMPUS

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Captcha * Time limit is exhausted. Please reload CAPTCHA.