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: