Agile Retrospektive – eine Horrorstory

Was ist eine Retrospektive?

Wenn wir in einem agilen Projekt von einer Retrospektive sprechen, meinen wir damit ein Meeting des agilen Teams, bei dem alle über die letzte Iteration reflektieren und beleuchten, was gut und was nicht so gut gelaufen ist.

Wieso wird überhaupt eine Retrospektive in einem Agilen Prozess benötigt?

Für mich ist die Retrospektive das Kern-Meeting eines jeden agilen Prozesses. Durch die Retrospektive kommt Veränderung und hoffentlich Verbesserung in das Team und den Prozess, durch das Erarbeiten der Schmerzen, aber auch der Stärken im Team. Bei dem Treffen kann man die Schmerzen angehen und die Stärken weiter ausbauen.

Die Retrospektive verfolgt das Prinzip „Inspect and Adapt“. Das heißt, es findet ein regelmäßiges Überprüfen des Standpunktes des Teams statt (Inspect) und im Anschluss wird analysiert, was optimiert werden kann und wie man diese Änderung(en) umsetzt (Adapt).

Am Ende einer Retrospektive geht das Team mit beispielsweise einem SMART Goal (Specific Measurable Accepted Realistic Time Bound) aus dem Meeting. In den nachfolgenden Retrospektiven reflektiert das Team, ob das SMART Goal eingehalten wurde und den versprochenen Effekt hatte. Auch hier kommt das Inspect and Adapt-Prinzip zur Anwendung.

Meistens wird eine Retrospektive in fünf Phasen abgehalten.

Die 5 Phasen einer Retrospektive

• Intro / Rahmenbedingungen schaffen / Set the stage: In dieser Phase versucht das Team, eine Umgebung für die folgenden Phasen zu schaffen. Ein Herrausreißen aus dem Alltag ist hierbei erwünscht.
• Daten / Informationen sammeln / Gathering data: Hier wird versucht, Informationen der letzten Iteration zu sammeln.
  • Zum Beispiel: Was ist besonders gut gelungen? Was muss sich ändern? Womit kann das Team (nicht) länger leben?
• Erkenntnisse entwickeln / Einsichten gewinnen / Generate Insights: Das Ziel dieser Phase ist es, das „Warum?“ zu ermitteln und eine Antwort darauf zu generieren.
  • Zum Beispiel: Erkenntnis aus Phase 2: „Es fehlt an Kenntnis wie der Produktfortschritt gerade ist.“
    • Warum? => Es wurde zu wenig Transparenz geschaffen. / Es gibt keine Synchronisationspunkte.
• Maßnahmen beschließen / Entscheidungen treffen / Define action / Decide what to do: Hier werden konkrete Maßnahmen beschlossen, um das Problem aus Phase 2 mit den Erkenntnissen der 3. Phase zu beheben.
  • Um beim Beispiel zu bleiben: Möglichkeiten, Transparenz zu schaffen: Klar ersichtliches Scrum- / Kanban- / Projekt- / Task-Board. Offen hängender Sprint / Project Burndown Chart. Daily Standup zum Synchronisieren.
• Abschluss / Close: Diese Phase hat kein „klares Ziel“. Meist wird nochmal ein Rückblick auf die Retrospektive geworfen und noch eine Aktivität zur Motivation abgehalten, um damit die Retrospektive abzurunden.

Die Techniken einer Retrospektive

Für jede Phase der Retrospektive findet man in der Literatur diverse Aktivitäten, Techniken, Methoden und Spiele, um das Ziel der jeweiligen Phase zu erreichen. Da dies den Rahmen des Artikels sprengen würde, möchte ich den Lesern den Retromaten empfehlen, der mir sehr geholfen hat beim Einstieg in die Welt der Retrospektive.

Die Horror Story

WARNUNG: Die Nachfolgende Geschichte ist frei erfunden und mag Sarkasmus enthalten, aber so mancher Entwickler mag sich hier wohl wiederfinden!

Prolog

Softwareentwickler der heutigen Zeit haben einen Terminkalender, der von oben bis unten mit Terminen gespickt ist. Hier ein Meeting, da ein Jour-Fix und immer mal wieder dieses Daily Standup. Dann kommt dieser über-motivierte Scrum Master auch noch an mit: „Hey der Sprint ist bald vorbei!“. Und schon ist es geschehen: Sprint Review, Sprint Retrospektive, Sprint Planning, etc.

Review – schön und gut. Mal sehen, was andere so gemacht haben. Planning ist notwendig, sehe ich ja ein. Aber diese Retro…. immer wieder diese Retro. Gefühlt jede Woche halten wir dieses Meeting und alles, was wir dort tun, ist Kaffee trinken und reden. Produktionswert tendiert gegen Null.

Die Retrospektive aka Das Jammermeeting

Hier ein kleiner Überblick wie eine Retro aussehen kann (aber nicht sollte) und wie Teammitglieder darüber denken:

• • Die Retrospektive muss nicht moderiert werden. Das Team ist schon erwachsen genug, um ein Gespräch zu führen.
  • Vorbereitung auf eine Retrospektive oder Gedanken an den letzten Sprint brauche ICH mir sowieso nicht machen. DAS erarbeiten ja andere für mich.
  • Es heißt immer „Sei pünktlich“ und „Das Meeting ist timeboxed“. Richtig effizient ist es doch nur, wenn das Team später kommt und es möglichst schnell vorbei ist. Vor allem bei den vielen Meetings. Zack Zack müssen da die Vorschläge kommen. Erarbeiten haben sie gesagt.*pfttt*.
  • Für mich ist die Retro auch nur ein „Selbsthilfeprogramm für Arbeiter“. Jeder darf mal erzählen, welche Probleme und Bedürfnisse er hat.
  • Wenn ein Thema mal wieder länger dauert, schnapp ich mir einen Schokoriegel und lass sie einfach im Kreis diskutieren. Ist doch auch schön wie man immer wieder am Anfang einer Diskussion rauskommen kann.
  • Aktionen/Maßnahmen/ Smart Goals definieren… ja ich hab mal gehört, dass das andere so machen, aber sind wir mal ehrlich: Jetzt diskutieren wir schon ewig drum herum und dann sollen wir uns auch noch auf eine Problemlösung einigen? Ich hab noch anderes zu tun!
  • Am Ende erkläre ich am besten jedem noch einmal, dass wir mehr leisten müssen und die Arbeit so nicht akzeptabel ist! Wir müssen deutlich effizienter werden. Positive Motivation braucht nun echt keiner!

• Wenn wir doch mal glücklicherweise sowas wie ein Smart Goal definieren,ist das ja eh egal. Hält sich keiner dran und am Ende des nächsten Sprints ist es sowieso vergessen!
• Es soll sowas wie 5 Phasen einer Retrospektive geben. Ich denke, die lauten folgendermaßen: Kaffee holen, Füße auf den Tisch, Schlafen, Füße vom Tisch, Neuen Kaffee holen.
• Wird ein Problem erkannt, denk nicht drüber nach, wie es behoben werden könnte, sondern suche einen Schuldigen. Einer muss es ja gewesen sein.

Wenn sich jemand in meiner „Horror Story“ wiederfindet, wäre es vielleicht gar nicht schlecht, von einem Agile Coach beraten zu werden, wie eine Retrospektive richtig ablaufen soll.