Scrum-Retrospektive mit dem Spotify Squad Health Check

Spotify organisiert seine Teams in sogenannten Tribes und Squads. Ein Squad ist dabei ein kleines interdisziplinäres, selbstorganisiertes Team, das normalerweise nicht mehr als 8 Mitglieder hat. In regelmässigen Abständen nutzt Spotify den «Squad Health Check» um den Teams zu helfen, sich zu verbessern. Wichtig dabei ist, dass das Resultat dieses Health Checks kein Report an das Management ist, sondern dem Team selber hilft, Stärken und Schwächen zu erkennen und sich über die Zeit zu verbessern.

Als Scrum Master unseres Scrum-Teams «MyDigicomp / Kiosk» führte ich zum Abschluss des letzten Jahres diesen Health Check mit dem Team durch. Ich bin schon vor längerer Zeit auf dieses Modell aufmerksam geworden und fand, dass nach 6 Sprints eine gute Gelegenheit war, das Modell einzuführen. Das Team «MyDigicomp / Kiosk» besteht aus 2 Product Ownern und den Entwicklern, die sich um die Weiterentwicklung unserer digitalen Produkte kümmern.

Wie funktioniert das Squad-Health-Check-Modell?

Das Spotify-Health-Check-Modell wurde bereits 2014 von Henrik Kniberg und Kristian Lindwall in einem Blogbeitrag ausführlich beschrieben (Squad Health Check model – visualizing what to improve, https://labs.spotify.com/2014/09/16/squad-health-check-model/)

Ich beschreibe hier nochmals kurz die wichtigsten Eckpunkte.

In der «Grundversion» besteht der Health Check aus 11 Dimensionen, in welchen sich das Team bewerten muss. Die Dimensionen werden durch eine Karte repräsentiert, auf der ein gutes und ein schlechtes Beispiel abgebildet ist. Die Beispiele sind jeweils das extreme Ende der Skala.

Die Dimensionen

• Spass
• Einfachheit des Releases
• Mission
• Support (innerhalb des Teams)
• «Gesundheit» der Codebase
• Lernen
• Wertgenerierung
• Passende Prozesse
• Geschwindigkeit
• Teamwork
• Bauern oder Spieler (kann das Team selber entscheiden, was es tut)

Eine Vorlage der Spotify Squad Health Check-Karten kann hier heruntergeladen werden.

Die Dimensionen sind beliebig erweiterbar oder austauschbar. So kann sich z.B. ein Scrum-Team, das keine Software ausliefert, die Dimension «Gesundheit der Codebase» sparen und durch eine passende ersetzen. Das Modell ist also für jeden Kontext geeignet.

Bewerten der Dimensionen

Das Team geht dann jede Dimension in einer Bewertungs- und Diskussionsrunde durch. Zuerst werden die Beispiele auf der Karte (positiv & negativ) vorgelesen. Danach gibt es eine Abstimmung (z.B. mit Punkten), ob man die Dimension positiv, neutral oder negativ bewertet. Dabei hat jedes Teammitglied eine Stimme.

Wichtig: Eine positive Bewertung bedeutet nicht, dass alles perfekt ist. Das Team drück damit lediglich aus, dass es mit der jetzigen Situation zufrieden ist.

Anschliessend können einzelne Teammitglieder ihre Meinung in einer kurzen Diskussion einbringen. Es hilft, diese direkt festzuhalten. Die Diskussion ist sowohl für das Team selber wie auch für mich als Scrum Master spannend, da das Team schnell Ideen entwickeln kann und ich als Scrum Master sehe, wie ich das Team unterstützen kann.

Zuletzt wird noch eine Tendenz angegeben. Hat sich diese Dimension seit dem letzten Health Check oder seit Beginn verbessert ↗, verschlechtert ↘ oder ist sie gleich geblieben →?

Für den Health Check sollten ca. 60 bis 120 Minuten eingeplant werden.

Das Resultat

Grafisch dargestellt sieht das dann so aus:

Diese Darstellung hilft, das Resultat einzelner Teams über die Zeit oder auch zwischen einzelnen Teams zu vergleichen.

Hat sich der Squad Health Check für uns gelohnt?

Die Methode bot dem Team eine gute  Möglichkeit, viele verschiedene Gesichtspunkte ihrer Arbeit anzusprechen. Die Dimensionskarten gaben dem Team einen guten Leitfaden. Wir haben die Möglichkeit für eigene Dimensionen noch nicht genutzt, werden das aber wahrscheinlich in einer weiteren Runde nutzen.

Die Beispiele auf den Dimensionskarten sind (bewusst) sehr extrem gewählt (z.B. «Our code is a pile of dung, and technical debt is raging out of control»). Das führt meiner Meinung nach tendenziell eher zu positiveren Bewertungen – wer gibt schon zu, dass die Codebase ein Haufen Mist ist.

Als Team konnten wir aber in den Diskussionen 7 Massnahmen definieren, in denen wir Verbesserungen vornehmen können.

Dies sind:

• Optimierung des Release-Prozesses
• automatisierte Tests ausbauen
• Vision / Mission unseres Produktes schärfen und weiter in die Digicomp hineintragen
• Codebases sauber halten & technische Schulden abbauen
• Zufriedenheit der Stakeholder steigern
• Value Poker im Backog-Refinement einsetzen
• Aufgaben für den Support (Daily Business) besser kanalisieren
• Achtung: Im Planning nicht überschätzen!

Einige der Massnahmen können direkt umgesetzt werden. Andere wiederum müssen konkretisiert und in die bestehenden Prozesse eingebaut werden.

Was es zu beachten gilt

Der Health Check sollte wirklich nur für das Team und den Scrum Master eingesetzt werden und nicht als Bewertungsinstrument für das Management missbraucht werden. Es sollte also keine Incentives geben, wenn das Team besonders gute «Health Check»-Resultate vorweisen kann. Ein Team sollte ehrlich zu sich selber sein können.

Ebenso kann das Vergleichen von Teams anhand des Modells heikel sein: Jedes Team bewertet sich nach eigenen Gesichtspunkten. Das verhindert eine faire Vergleichbarkeit. Für den Scrum Master kann ein Vergleich zwischen den Teams trotzdem interessant sein, um Dimensionen zu identifizieren, in denen evtl. alle oder mehrere Teams Unterstützung brauchen.