Was ist das „Squad Health Check Model” von Spotify?
Viele Unternehmen experimentieren mit verschiedensten Möglichkeiten, um bewerten und visualisieren zu können, wo ihre Teams stehen. Normalerweise geschieht dies mit Hilfe von sogenannten Maturity Models, also Reifegradmodellen, die eine Weiterentwicklung durch verschiedene Ebenen darstellen.
Die Absichten hinter derartigen Modellen sind in der Regel positiv – beispielsweise wenn Manager, Führungsverantwortliche oder Coaches in größeren Organisationen ein besseres Gefühl dafür bekommen möchten, wo ihr Fokus in Hinblick auf Verbesserungen und Probleme liegen sollte, oder wenn sie ihren Teams helfen möchten, reflektierter zu werden, damit auch sie sich besser auf ihre eigenen Verbesserungen konzentrieren können.
Wir nennen es jedoch lieber „Health Check Model” (dt. Gesundheitscheckmodell) als „Maturity Model”, da Letzteres…nun ja…etwas bevormundend klingt. Außerdem umfassen die meisten unserer Modelle nicht die Weiterentwicklung über verschiedene Stufen. Die primäre Zielgruppe ist zudem das Team selbst und nicht das Management.
Die Verbesserung der Organisation gleicht oft einem Ratespiel (woher weiß man, was verbessert werden muss? Und woher weiß man, ob sich etwas verbessert?). Ein systemischer Ansatz mit einer eindeutigen Visualisierung kann dieses Ratespiel auf ein Minimum reduzieren.
Ok, aber funktionieren solche Modelle tatsächlich?
Es kommt darauf an. In manchen Fällen können diese Modelle wirklich hilfreich sein. Manchmal ist es eher so „meh” – die Leute erfüllen ihre Pflicht und nehmen an Workshops, Umfragen o.ä. Teil, doch die daraus entstehenden Daten werden ignoriert.
Aber seien Sie vorsichtig. Wir haben schon gesehen, wie derartige Modelle bei einigen Unternehmen zu richtigen Monstern wurden; ein systemisches Tool der Unterdrückung, das für Suboptimierung und Angst sorgt. Die Manager nutzen das Reifegradmodell, um Teams zu bewerten und gegeneinander aufzuhetzen, und die Teams verheimlichen ihre Probleme, um gut dazustehen. Und das ist überhaupt nicht gut!
Obwohl der potenzielle Schaden wahrscheinlicher ist als der potenzielle Vorteil, GIBT ES einen potenziellen Vorteil und es gibt Möglichkeiten ein Desaster zu vermeiden.
Bei Spotify habe ich über einige Jahre etwas damit experimentiert und Möglichkeiten gefunden, die ganz gut funktionieren (also mehr Vor- als Nachteile haben) – bestenfalls sind sie „hilfreich”, im schlimmsten Fall „meh” und bisher waren sie noch nie ein „Desaster”. Dieses Health Check Model haben wir auch bei einigen anderen Unternehmen eingeführt und ähnliche Resultate erzielt, daher dachte ich, es sei an der Zeit, einen Artikel darüber zu schreiben.
Für wen ist das Health Check Model gedacht?
Beim Health Check Modell eines Squads (unser Begriff für ein kleines, interdisziplinäres, selbstorganisiertes Entwicklungsteam) gibt es hauptsächlich zwei Stakeholder:
1) Das Squad selbst
Dadurch, dass die einzelnen Indikatoren besprochen werden, können die Mitglieder des Squads besser verstehen, was für sie funktioniert und was nicht. Die große Bandbreite an Fragen hilft ihnen, ihren Horizont zu erweitern. Vielleicht sind ihnen die Qualitätsprobleme des Codes bewusst, aber sie haben nicht wirklich über den Wert aus Sicht des Kunden nachgedacht oder darüber, wie schnell sie dazulernen können. Außerdem werden sowohl die guten Dinge als auch die negativen Punkte aufgezeigt.
2) Leute, die das Squad unterstützen.
Manager und Coaches, die außerhalb des Teams arbeiten (oder zumindest zum Teil außerhalb des Teams arbeiten) bekommen eine Übersicht über all die Dinge, die funktionieren und die nicht funktionieren. Zusätzlich können sie Muster zwischen verschiedenen Squads erkennen. Wenn man dutzende Teams hat und nicht mit jedem über alles sprechen kann, kann eine solche Zusammenfassung dabei helfen, herauszufinden, wie man seine Zeit am besten nutzen kann und mit wem man über was sprechen sollte.
Sich des Problems bewusst zu sein, ist der erste Schritt zur Lösung eines Problems. Diese Art der Visualisierung macht es wesentlich schwerer, ein Problem zu ignorieren.
Wie wir das bei Spotify machen
Hauptsächlich tun wir drei Dinge:
Wir führen Workshops durch, in denen die Mitglieder eines Squads ihre aktuelle Situation anhand verschiedener Aspekte besprechen und beurteilen (z.B. Qualität, Spaß, Wert usw.)
Wir erstellen eine graphische Zusammenfassung des Ergebnisses
Wir helfen den Squads dabei, sich zu verbessern
Wir haben verschiedene Varianten. Eine nennen wir einfach „Squad Health Check Model”, andere heißen beispielsweise „Fluent@Agile-Spiel” oder „Quarterly Reflection”. Das „Health Check Model” ist eine verbesserte Version der dreimonatlichen „Autonomous Squads”-Untersuchung, die 2012 im Artikel Scaling Agile @ Spotify erwähnt wurde.
Hier ist ein echtes Beispiel für das Health Check Modell eines „Tribes”:
Hier ist dargestellt, wie 7 verschiedene Squads ihre eigene Situation einschätzen. Die Farben zeigen, wie es aktuell ist (grün=gut, gelb=einige Probleme, rot=sehr schlecht). Die Pfeile geben den Trend an (wird es eher besser oder schlechter?).
Wenn Sie sich das Diagramm ein paar Minuten genau anschauen, werden Ihnen einige interessante Dinge auffallen:
In den Spalten können Sie die Hauptunterschiede zwischen den verschiedenen Squads erkennen. Squad 4 ist mit so ziemlich allem zufrieden. Squad 2 hat viele Probleme, jedoch gibt es einen positiven Trend bei fast allen Punkten.
In den Reihen können sie systemische Muster erkennen. Jedes Squad hat Spaß bei der Arbeit (und der Trend geht sogar noch weiter nach oben!). Motivation scheint demnach kein Problem zu sein. Allerdings macht der Release-Prozess Probleme und die Codebasis sieht auch nicht allzu gut aus. Mit der Zeit wird das sicherlich auch den Spaßfaktor bei der Arbeit beeinträchtigen.
Im Gesamtbild kann man sehen, dass fast alle Pfeile nach oben zeigen, im gesamten Diagramm gibt es nur 2 Pfeile nach unten. Das bedeutet, dass der Verbesserungsprozess (der wichtigste Prozess überhaupt) scheinbar funktioniert.
Dies ist natürlich nur eine ungefähre Wiedergabe der Realität („Alle Modell sind falsch, aber einige sind nützlich.” – George Box). Daher ist es eine gute Idee, alles noch einmal zu überprüfen, bevor man konkrete Maßnahmen ergreift.
Läuft bei Squad 4 wirklich alles so gut oder sind sie nur optimistisch und sehen ihre Probleme nicht? Die meisten Squads denken, dass sie ihren Kunden Wert liefern – aber woher wissen sei das? Basiert diese Aussage auf einer Wunschvorstellung oder auf echtem Kunden-Feedback?
Squad 4 aus unserem Beispiel wurde tatsächlich erst eine Woche, bevor der Health Check durchgeführt wurde, zusammengestellt. Sie waren daher definitiv noch in der Orientierungsphase (auch Forming-Phase oder Honeymoon-Phase genannt). Aus diesem Grund benötigte sowohl Squad 2 als auch Squad 4 eine Menge Unterstützung.
Die einfache Auslieferbarkeit war hier ein großes Problem. Also wurde sich mehr auf Dinge wie Continuous Delivery (kontinuierliche Auslieferung) konzentriert und bald konnte man eine deutliche Verbesserung erkennen.
Bitte denken Sie daran, dass dies ein Selbstbewertungsmodell ist; das auf der Ehrlichkeit und der subjektiven Meinung der Squad-Mitglieder basiert. Es funktioniert also nur in einer vertrauensvollen Umgebung, in der die Leute sicher sein können, dass ihre Manager und Kollegen in ihrem Interesse handeln. Die Daten zu sammeln ist recht einfach – es geht also hauptsächlich darum, dass es keine konkreten Gründe dafür geben sollte, dies zu tun.
Glücklicherweise gibt es bei Spotify eine solch vertrauensvolle Umgebung und die Manager und Coaches sind sehr darauf bedacht, zu vermitteln, dass dies ein Tool zur Unterstützung und nicht zur Bewertung der Squads ist.
Wie wir die Daten sammeln
Wir haben die Erfahrung gemacht, dass Online Surveys für solche Zwecke totaler Mist sind. Das liegt hauptsächlich daran, dass sie keine Konversation ermöglichen, und das ist nun mal das Wertvollste daran. Während die Squad-Mitglieder sich unterhalten, gewinnen Sie weitere Erkenntnisse, und der Coach findet heraus, wie er den Squads effektiv weiterhelfen kann. Die Daten alleine zeigen einem nur einen kleinen Teil des Gesamtbildes, was irreführend sein kann.
Also organisieren wir (normalerweise agile Coaches) Workshops mit den Squads und regen eine direkte Konversation zu den verschiedenen Indikatoren des „Health Check Models” an. Ein bis zwei Stunden reichen dafür meist aus.
Für die Moderation nutzen wir ein Set sogenannter „Awesome Cards”. Jede Karte steht für einen der Indikatoren und beinhaltet sowohl ein „Example of Awesome” (Beispiel für etwas Großartiges) als auch ein „Example of Crappy” (Beispiel für etwas, das schlecht läuft).
Set besteht normalerweise aus etwa 10 Karten. Hier das Beispiel eines kompletten Sets:
Bei jeder Frage werden die Squads gefragt, ob sie sich eher bei „Awesome” oder „Crappy” sehen. Um es ihnen zu erleichtern, sich über eine Farbe für die Indikatoren und den jeweiligen Trend (stabil, Aufwärts-/Abwärtstrend) einig zu werden, nutzen wir ganz grundlegende Workshop-Methoden wie z.B. Dot Voting.
Hier sind die Karten als PDF-Download
Wir halten es mit drei Stufen recht simpel (grün/gelb/rot). Die genaue Definition der Farbkodierung kann variieren, basiert aber auf folgenden Aussagen:
Grün bedeutet nicht zwingend, dass alles perfekt ist. Es bedeutet nur, dass das Squad zufrieden ist und momentan keinen großen Bedarf für Verbesserungen sieht.
Gelb bedeutet, dass es einige Probleme gibt, die gelöst werden sollten aber kein Desaster sind.
Rot bedeutet, dass etwas wirklich schief läuft und verbessert werden muss.
Ja, dies sind subjektive Daten. Theoretisch steht es jedem Squad frei, auch objektive Daten (Zyklusdurchlaufzeit, Anzahl an Defects, Velocity usw.) einzubeziehen. Das tun jedoch sehr wenige. Das liegt daran, dass Squads auch objektive Daten interpretieren und entscheiden müssen, ob diese bedeuten, dass man ein Problem hat oder nicht. Am Ende des Tages ist daher ohnehin alles subjektiv. Wenn sich etwas wie ein Problem anfühlt, ist es auch ein Problem.
Manchmal kombinieren wir das mit Retrospektiven, z.B. indem wir eine Karte auswählen und uns dann Verbesserungsmaßnahmen dafür überlegen.
Welche Fragen sollte man stellen?
Wenn Sie sich die oben genannten Beispiele anschauen, werden Sie erkennen, dass die Fragen nicht immer die gleichen sind. Dies ist ein guter Leitfaden:
Die Fragen sollen eine große Bandbreite an verschiedenen Perspektiven abdecken.
Diese Fragen sind lediglich ein Ausgangspunkt, eine beispielhafte Vorauswahl. Die Squads dürfen frei entscheiden, ob sie Fragen entfernen, hinzufügen oder ändern wollen, wenn sie glauben, dass dies sinnvoll ist.
Versuchen Sie die Anzahl der Fragen auf ca. 10 Fragen zu limitieren. Bei mehr Fragen kann es schnell zu Überlappungen kommen, weshalb diese entfernt werden können.
Man sollte darauf achten, dass sich die Fragen auf das Umfeld beziehen, in denen ein Squad arbeitet, und nicht auf harte Daten (wie z. B. die Velocity). Dadurch wird das Ganze weniger bedrohlich und es wird noch einmal betont, dass es dabei um Unterstützung und Verbesserung geht – und nicht um Bewertung.
Unsere Annahme (ob wahr oder nicht) ist, dass ein Squad eine intrinsische Motivation hat, erfolgreich zu sein und die unter den gegebenen Umständen bestmögliche Leistung zu erbringen.
Wie oft messen wir die Gesundheit der Squads?
Wie gesagt haben wir verschiedene Modelle auf die wir zurückgreifen, daher ist das sehr unterschiedlich. Wir haben noch keinen bestimmten „perfekten Zeitintervall” für derartige Dinge gefunden (und das werden wir wohl auch nie).
Quartalsweise scheint jedoch ein guter Ausgangspunkt zu sein. Monatlich ist wohl ein wenig zu häufig (den Leuten wird es dann schnell lästig und die Daten ändern sich nicht schnell genug). Zweimal im Jahr scheint zu selten zu sein (in einem halben Jahr kann einfach zu viel passieren). Aber wie gesagt, das ist immer unterschiedlich.
Fazit – Woran Sie denken sollten, wenn Sie das ausprobieren möchten
Ein solches Modell KANN dabei helfen, Verbesserungen voranzutreiben. Es kann aber auch eine gesamte Unternehmenskultur auf den Kopf stellen, wenn man es nicht korrekt macht! Daher sollte man immer mit Vorsicht vorgehen.
Hier sind einige Richtlinien, die die Wahrscheinlichkeit des Erfolges erhöhen:
Seien Sie sich über die Motive für die Einführung des Modells im Klaren. Es sollte immer um Verbesserung gehen, nicht um Beurteilung.
Sie sollten die Daten hauptsächlich durch persönliche Kommunikation sammeln, nicht durch Online-Umfragen. Dieser Prozess sollte interessant sein und Spaß machen.
Involvieren Sie die Teams bei der Anwendung des Modells und lassen Sie sie Anpassungen nach ihren Bedürfnissen vornehmen.
Die Akzeptanz des Teams ist wichtiger als die Konsistenz der Daten. Wenn Team A ein etwas anderes Set an Fragen wählt als Team B, ist das okay (auch wenn die Zusammenfassung dann etwas unübersichtlicher wird).
Achten Sie darauf, dass es keinen Anreiz gibt, zu schummeln. Es sollte keine Gründe für ein Team geben, sich besser darstellen zu wollen, als es der Fall ist.
Finden Sie eine einfache Möglichkeit, die Daten zu visualisieren. Je offensichtlicher und intuitiver die Visualisierung ist, desto höher ist die Wahrscheinlichkeit, dass sie genutzt wird.
Versuchen Sie, die Teams nicht miteinander zu vergleichen. Wenn Team A die Punkte hauptsächlich mit grün bewertet und Team B zum größten Teil mit rot, bedeutet das nicht automatisch, dass Team A „besser” ist. Es könnte genauso gut bedeuten, dass Team A einen einfacheren Kontext hat, optimistischer ist oder dass Team B ehrlicher ist, was Schwierigkeiten angeht. Egal, was der Grund dafür ist, es bedeutet einfach nur, dass Team B etwas mehr Unterstützung braucht. Die Haltung des Managers sollte sein „Wie kann ich helfen?” und nicht „Warum seid ihr so viel schlechter als die anderen?”.
Machen Sie ein Follow-up. Fragen Sie Fragen wie: „Hilft euch dieses Modell?”, „Wenn wir keine Health Checks mehr durchführen würden, würdet ihr sie dann vermissen?” oder „Wie könnten wir dieses Modell noch nützlicher gestalten?”. Das Modell (und die Art und Weise, wie Sie es anwenden) muss kontinuierlich verbessert werden.