Retrospektive: wie man eine Sailboat-Retro mit einem Kanban kombiniert

Hier ein Beispiel aus unserer Best Practices-Sammlung, wie man eine Retrospektive möglichst gut strukturieren kann und gleichzeitig das Team auf ein gemeinsames Ziel einstellt. Viele Teams schätzen diese Technik aufgrund ihrer Einfachheit. Sie hilft dem Team aber nicht nur dabei, interne Schwachpunkte oder bereits gut funktionierende Elemente zu identifizieren. Sie geht noch einen wichtigen Schritt weiter, in dem das Team mögliche Lösungen für Impediments sammelt und konkrete Maßnahmen für die nächste Iterationen sammelt, die klar machen, welche Optimierungen wir fokussiert angehen werden. Um das Ganze transparent zu halten, haben wir die Sailboat-Retrospektive mit einem Kanban Board verknüpft.

Wie funktioniert die SailBoat-Retrospektive?

1. Vorbereitung

Diese Retrospektive ist sehr einfach gehalten und benötigt keinen großen, zeitlichen Aufwand. Als erstes zeichnet Ihr ein Segelschiff mit einem Anker auf, welches den Namen eures Teams trägt. Der Anker auf dem Segelboot symbolisiert alles, was euch auf der Reise Richtung Ziel aufhält und blockiert. Dann zeichnet Ihr eine Insel, welche euer gemeinsames Ziel / Vision für den nächsten Sprint (oder auch nächsten Sprints) darstellen soll und auf dieses euer Boot zusteuert.

Vor der Insel (Ziel) zeichnet Ihr Felsen, welche aus dem Wasser ragen. Diese repräsentieren die Risiken, welchen Ihr auf dem Weg zum Ziel begegnen könntet. Die Wolken und die Windzüge, zeichnet Ihr hinter das SailBoat. Sie stellen den „Rückenwind“ der euch hilft das Ziel zu erreichen, dar. Hier solltet ihr also alles sammeln, was im Moment besonders gut läuft und was ihr an Praktiken auch beibehalten wollt.

Das Segelboot wird von einer Ankerkette gehalten. Diese repräsentiert unsere Impediments, also die kleinen und großen Hürden im Alltag, die Euch bremsen. Was Euch jetzt noch fehlt, sind Fakten. Wenn Ihr Euer Jira entsprechend aufgesetzt habt, könnt ihr sehr viele hilfreiche Informationen für Eure Retrospektive bereits als Report ziehen. Auf diese gehen wir gleich etwas mehr ein.

2. Fakten sammeln und Brainstorming

Jetzt schließt sich ein Brainstorming an, welches Euch eine erste Ideensammlung in der Retrospektive ermöglicht. Wir haben gute Erfahrungen damit gemacht, dass jedes Teammitglied sich 10min Zeit nimmt und für sich erst einmal selbst seine Gedanken über den letzten Sprint macht. Jeder schreibt seine Punkte auf jeweils einen Post-It. Danach geht es reihum mit der Vorstellung der Zettel los, wobei jeder immer nur einen Zettel an das Board bringen und kurz erklären darf. Das ganze geht jetzt immer im Kreis bis alle Zettel platziert wurden.

Holt anschließend die Reports aus Eurem Jira hervor. Für unsere Teams haben sich folgende Issue Types als besonders wertvoll erwiesen:

Bugs
Wir wollen wissen, wie viele und welche Arten von Bugs wir im letzten Sprint aufnehmen mussten. Bugs sind größere oder kleinere Fehler, die in der Produktivumgebung auftauchen und die wir nicht beim Testen identifizieren konnten. In der Regel, fallen diese Fehler erst im Live-Betrieb beim User auf.

Test Issues
Sofern unser Testing funktioniert, werden wir auch in der QA immer wieder Dinge finden, die für uns Nacharbeit bedeuten. Auch aus einer gemeinsamen Code Review können solche Mehrarbeiten herauskommen. Test Issues werden also vom Team selbst identifiziert und schlagen nicht bis in die Live-Umgebung durch, da sie bereits vorher entdeckt wurden.

Dependencies
Gerade bei größeren Produkten kann es sein, dass man Abhängigkeiten zu anderen Teams hat. Manchmal stellt das eigene Team dann während dem Sprint fest, dass man auf die Zuarbeit anderer angewiesen ist. Das ist natürlich ärgerlich. Die eigene Arbeit kann dann nicht fertiggestellt werden.

Rückfragen
Es kommt immer wieder vor, dass das Team zu einer bereits angenommenen User Story noch Rückfragen hat. Auch das wollen wir messen und prüfen, ob wir die Anforderungen zukünftig detaillierter beschreiben müssen.

Ihr habt in Eurer Sailboat-Retrospektive jetzt ein sehr gutes Bild darüber, wie gut oder schlecht Euer letzter Sprint gelaufen ist. Ihr wisst außerdem, wo ihr hinsichtlich der eigenen Qualität steht.

3. Besprecht die Impediments und legt konkrete Maßnahmen fest

Im besten Fall besprecht ihr die einzelnen Punkte erst jetzt in eurer Retrospektive. Fangt mit der Vision und dem Positiven an und geht auf die gesammelten Punkte ein, welche als Rückenwind und somit als hilfreich gesammelt wurden. Diese Punkte sind für das Team wichtig. Sie helfen euch und sollten aus diesem Grund beibehalten oder gar verstärkt werden.

Sprecht nun über die von euch identifizierten Risiken und wie man diese mindern könnte. Klärt, mit welchen Maßnahmen Ihr diese Risiken minimieren könntet. Danach könntet Ihr Euch die Blocker anschauen, die man als Anker identifiziert hat. Das hier sind die Themen, die Euch am meisten bremsen und um die sich der Scrum Master in erster Linie kümmern sollte. Einige Teams nennen diese auch Major Impediments – nennt sie wie Ihr wollt, aber diese sollten in der Regel höchste Priorität haben.

Als nächster Schritt geht Ihr auf die Punkt ein, welche euch verlangsamen. Welche Wellen schlagen Euch entgegen und halten Euch somit etwas auf. Welches sind die größten und wichtigsten Probleme, die schnell einen Lösungsansatz benötigen um aus dem Weg geräumt zu werden. Diese zu identifizieren sollte ein Hauptziel eurer Retrospektive sein.

Ein paar Tipps:

  • Versucht in der Retrospektive möglichst frühzeitig die Risiken auf eurem Weg zu erkennen (z.B. Abhängigkeiten zu anderen Teams oder Ressourcen-Engpässe)
  • Findet möglichst für alle Risiken, Blocker und Bremser (oder einfach Impediments) einen Verantwortlichen in der Retrospektive, der sich aktiv um die Lösung/Durchführung dieser Maßnahmen kümmert
  • Einigt Euch auf ein gemeinsames Ziel für den nächsten Sprint (z.B. „wir wollen unsere Tests automatisieren) – das hilft Euch, am Ball zu bleiben

Wann kannst du diese Technik anwenden?

Wir sind der Meinung, dass diese Art der Retrospektive durch Ihre Einfachheit immer angewendet werden kann und keinen besonderen Anlass braucht. Es ist auch kein bestimmter Reifegrad erforderlich. Die Vorbereitungszeit ist auch überschaubar – also: Let´s do it!

1 Comment

Comments are closed.

  1. […] der Retrospektive am Ende des Sprints betrachten wir die angelegten Burn-Down Charts. „Haben wir geschafft was wir […]

Log in with your credentials

Forgot your details?