Die Insel-Retrospektive

tl;dr

Ein Rockstar oder Held im Team birgt ein Risiko. Mit der Insel-Retrospektive kann das Team die Problematik eines zentralen Helden erkennen, indem wir schauen, was passieren würde, wenn unser Held plötzlich und unvermittelt auf eine einsame Insel verschwindet. In drei Schritten wird das Problem zunächst deutlich gemacht, dann Erkenntnisse gesammelt, um abschließend konkrete Maßnahmen zu beschließen, wie man das Problem angehen kann. Viel Spaß!

Einleitung

In vielen Teams gibt es eine Person, die aufgrund ihres Fachwissens, Erfahrung oder Persönlichkeit eine zentrale und exponierte Rolle im Team spielt. Häufig besitzt diese Person Wissen, welches andere im Team nicht haben. Ohne diese Person können wichtige Entscheidungen nicht getroffen, und bestimmte Aufgaben nicht erledigt werden. Diese Person hat in Bereichen ein “Kopfmonopol”. Diese Person ist der Held des Teams. Ein guter Held, der dem Team in schwierigen Situationen helfen kann, aber auch ein unverzichtbarer, ohne den es auch nicht wirklich geht.

Derartige Helden im Team sind aus verschiedenen Gründen problematisch:

  1. Sie sind ein Risiko für das Team. Fällt der Held aus (und wir sollten damit rechnen, dass das passiert), so droht im Extrem die Unfähigkeit zu Handeln. Das ist kritisch. Dieses Risiko wird häufig auch als der Bus-Faktor beschrieben.
  2. Helden können die Teamentwicklung behindern. Durch die Kopfmonopole sind die Verantwortlichkeiten häufig klar verteilt. Im Ergebnis führt das dazu, dass sich das Team eigene, möglichst unabhängige Aufgaben sucht, oder aber in einer passiven Rolle “nur” zuarbeitet.
    Beides ist nicht im Sinne eines kollaborativ arbeitenden, crossfunktionalen Team.

Es ist daher wichtig, dass das Team diese Problematik erkennt, und sich Maßnahmen überlegt, wie das Wissen besser im Team verteilt werden kann, um so mehr echte Kollaboration, Verantwortung und Identifikation im Team zu erreichen.

Ich habe mir dazu eine Retrospektive überlegt, mit der das Team sich dem Problem bewusst wird, Sorgen und Ängste äussert, und letztlich zu eine Reihe von Action-Items kommt, mit denen sie ihre Situation verbessern können.

Grobe Agenda (ca. 120 Minuten):

  1. Bewusstsein schaffen 15min
  2. Schick mal ne Karte 2*20min
  3. Troika Consulting 6*10min

Material:

  • Flipchart,
  • Dicke und dünne Stifte
  • PostIts (rot, gelb, grün), größere für Userstories
  • Blanke Karteikarten für Postkarten
  • Marker zur Markierung von Userstories (challenged, unmöglich)
  • Bindfäden zum Verbinden der Stories, Schere
  • Poststrips zum befestigen der Fäden und Postkarten

Bewusstsein schaffen

Im ersten Schritt (15min) soll deutlich gemacht werden, wie zentral die Rolle dieses Helden im Team ist. Dazu wähle ich aus dem Product-Backlog die nächsten anstehenden 5–8 Userstories aus. Diese müssen nicht “Ready” sein, sondern dürfen gerne auch noch in weiten Teilen unklar sein.

Wer arbeitet woran? Wer ist unser Held? Im ersten Schritt wird das Problem verdeutlicht.

Im ersten Schritt bringen wir die Teammitglieder auf der einen Seite, und die Userstories auf der anderen Seite des Flipcharts an. Die Aufgabe des Teams ist es nun sich mit den Aufgaben zu verbinden. Jedes Mitglied verbindet sich mit den Stories, bei denen es glaubt unterstützend oder führend mitzuarbeiten. Wo das Mitglied etwas beitragen?

Als Ergebnis ergibt sich dann die Verbindungen zwischen Teammitgliedern und Userstories. Die Anzahl der Verbindungen, die von einer Person ausgehen, schreiben wir neben die Person. Sie können ein Indikator dafür sein wer in unserem Team der Held ist.

Im dritten Schritt entfernen den Helden und alle seine Verknüpfungen zu den Userstories. Der Rest des Team diskutiert nun wie gefährdet die Userstories ohne unseren Held sind. Dabei hat es drei Optionen:

  1. Alles gut. Die Story schafft das Team! Vielleicht gibt es Mehraufwand durch Einarbeitung, aber das Team ist zuversichtlich, das es die Aufgabe im nächsten Sprint schaffen kann.
  2. Schwierig. Die Einarbeitung ist aufwendig und das Team ist nicht sicher ob es die Story schaffen kann. Wahrscheinlich nicht vollständig. Vielleicht auch gar nicht. In diesem Fall markiert das Team die Story mit einem Marker als “gechallenged” und erklärt wo es die Probleme sieht.
  3. Unmöglich. Die Einarbeitung ist zu aufwendig. Das Team sieht keine realistische Chance diese Stories zu schaffen. Auch in diesem Fall markiert das Team die Story mit einem Marker als “unmöglich” und erklärt wo es die Probleme sieht.

Schick mal ne Karte!

Wie es der Zufall will, fährt unser Held auf unbestimmte Zeit in den Urlaub auf eine einsame Insel. Überraschung! Die letzten Worte, die das Team noch bei der hastigen Abreise vernehmen konnte, waren: “Don’t Panic! Schickt doch mal ne Karte!”. Die Aufgabe für das Team im nächsten Schritt ist folgende:

Die verbliebenden Teammitglieder schreiben (10min) dem Helden eine Postkarte (Die Idee stammt übrigens hierher). Dabei ist ihre Kreativität gefordert. Auf einer Seite der Postkarte soll aufgemalt werden wie der Sprint laufen wird. Auf der anderen Seite richten die Mitglieder sie ein paar Sätze an den Helden. Warum ist es wichtig das er wiederkommt, Was sind ihre Sorgen, Fragen? Wo sind Sie zuversichtlich? Die Sätze können sowohl aus eigener als auch aus der Perspektive des Teams sein.

Das gleiche gilt für den Helden. Er schreibt ebenfalls eine solche Postkarte an das zurückgebliebene Team. Auf dieser findet sich als Bild seine Vorstellung des Sprints und ein paar Tipps und aufmunternde Worte.

Mit Hilfe von Postkarten werden Sorgen und Bedenken geäussert und so Erkenntnisse gesammelt.

Nun werden in drei Schritten die Karten vorgelesen und Erkenntnisse gesammelt. In der Abbildung sind diese drei Schritte von Links nach Rechts zu erkennen (die Bereiche “Cards”, “Dev” und “Team” habe ich dabei auf einem Flipchart untereinander gemalt).

Im ersten Schritt werden die Karten des Teams durch den Helden vorgelesen. Er beschreibt was er im Bild erkennt und liest die Karte vor. Der Scrum-Master notiert die “Grüße” am Flipchart und versucht einzuordnen ob diese eher persönlich (Dev) oder aus Sicht des Teams (Team) gekommen sind. Zum Schluß wird die Karte angeheftet (Cards).

Im zweiten Schritt wird versucht aus den verschiedenen Theman, die zur Sprache gekommen sind Cluster zu bilden.

Im letzten Schritt liest eines der Teammitglieder die Karte unseres Helden vor. Auch hier werden Karte und Hinweise (grüne Zettel) auf dem Flipchart notiert. Dabei versuchen wir die Hinweise und Tipps des Helden auf die Sorgen zu matchen. Nicht immer ist das möglich.

Erkenntnisse sammeln

Danach wollen wir versuchen daraus Erkenntnisse in einer offenen Diskussion zu generieren (20min). Was bedeutet das für das Team? Welche Hinweise unseres Helden können bei Problemen helfen? Welche Probleme bleiben nicht adressiert? Ebenfalls spannend zu sehen ist, ob es Ratschläge und Tips des Helden gibt, zu denen es gar keine passende Sorge gibt. Was hat das zu bedeuten? Welche technischen, menschliche und organisatorische Hinternisse könnten sich ergeben versucht die Probleme zu lösen? Bei Bedarf kann man die Liste der Probleme und Sorgen erweitern. Ich habe darauf aber verzichtet. Mir kam es darauf an sich dessen erstmal bewusst zu werden.

Troika Consulting

Im letzten Schritt soll das Team Maßnahmen erarbeiten, mit denen es die Auswirkung eines Ausfalls unseres Helden mindern kann. Dazu nutzen wir das Format der Troika Consulting aus den Libertating Structures. Die Durchführung unterscheidet sich ein bisschen je nachdem wer beraten wird.

Troika Consulting in drei Schritten

Team-Beratung

Bei der Team-Beratung lässt sich eines der zurückgebliebenen Teammitglieder zu einer der von ihm konkret geäusserten Bedenken beraten. Er stellt seine Sorgen kurz vor und es können Verständnisfragen gestellt werden. Danach beginnt die eigentlich Beratung. Die Beratung kann durch zwei beliebige Teammitglieder (auch der Held darf Teil davon sein) erfolgen. Am Ende nennt das Teammitglied seine Erkenntnisse und formuliert ein Action-Item welches er für sich im kommenden Sprint umsetzen will.

Helden-Beratung

Bei der Helden-Beratung läuft ein bisschen anders ab. Die Frage hier ist im Grunde klar: Wie kann ich (der Held) euch (das Team) am besten unterstützen? Was braucht ihr, Was soll ich tun? Es folgt die Beratung durch zwei Teammitglieder, an deren Ende der Held seine Erkenntnisse mitteilt und ein Action-Item formuliert.

Fazit

Die Retro habe ich mit einem meiner Teams durchgeführt. Das Team war sich der Problematik zwar bewusst, aber vielleicht nicht dem Ausmaß. Das hat sich geändert und das war eine gute und wichtige Erkenntnis. Die Ergebnisse in Form der Action-Items sind ein Schritt in die richtige Richtung. Das Team hat sich in dem Fall zu zwei Dingen entschlossen:

  1. Durcharbeiten von Tutorials, die vom Helden herausgesucht werden sollen, um den Einstieg in eine bisher unbekannte Technologie zu bekommen.
  2. Das Team macht sich in unseren “Skill-Portal” (interne Anwendung in der Leute ihre Kenntnisse pflegen können) schlau wer ausser unserem Helden noch in dieser Technologie unterstützen kann.

Wer mehr über mich und meine Arbeit als agiler Pfadfinder bei der Firma SALT AND PEPPER erfahren möchte, kann mir bei Twitter folgen.

Schreibe einen Kommentar