APM 7 – Retrospektive

Anfang und Begrüßung

Serie "Scrum Essentials", 4. Teil: Retrospektive — am Ende des Sprints kommt nach dem Review Meeting die Retrospektive (kurz: Retro).

Retrospektiven

Es geht darum, auf Personen, Beziehungen, Prozesse und Werkzeuge zu schauen (Was lief gut, was lief weniger gut?)  — Rückblick mit Fokus auf Veränderung — "Wie so immer im Agilen geht's ums Lernen" (Toby) — Wichtigstes Instrument für den Scrum Master (Wenn man die Retro immer macht, kommt man irgendwann zum richtigen Prozess)  — Buch: "Agile Retrospectives" (5 Phasen der Retrospektive) .

Phase 1: Set the stage / "Reinkommen"

(Aus dem alltäglichen ausbrechen, um in die Vogelperspektive zu gelangen)  — Eisbrecher: jeder soll am Anfang was sagen, damit man später auch spricht — ganz kurze Phase, vielleicht nur 1 Minute.

Phase 2: Gather Data / Daten erheben

Mad / Sad / Glad — bei Spielen versucht man zu gewinnen, bei der Retro wollen wir Erkenntnisse gewinnen — Es geht darum, möglichst viele oder möglichst die richtigen Daten zu finden, über die man hinterher sprechen kann — Kartenlimit bei Mad / Sad / Glad sorgt für Filter und Fokus — "Mad" ist nicht unbedingt eine Steigerung von "Sad".

Phase 3: Generate Insights / Erkenntnisse gewinnen

Daten betrachten und analysieren — Muster erkennen und bearbeiten — Wichtigestes Wort: Why? Warum? — "5 whys" als Technik an die unsprünglichen Gründe zu kommen — Schwierigster Teil der Retrospektive.

Phase 4: Decide what to do / Sich für Ziele entscheiden

"Actionable items" finden, auf die sich das Team als Maßnahme eignet — Wenn die Erkenntnisse aus "Generate insights" klar verstanden sind, findet man leicht gute Ziele — Akronym SMART (spezifisch, messbar, ausführbar, realistisch, terminiert) .

Phase 5: Close the retrospective / Retrospektive beenden

Für Mitarbeit bedanken, denn Retro ist Arbeit — Feedback zur Retro einholen (Delta / Plus)  — Ziel der Retro sind ein bis zwei Maßnahmen oder Experimente — In der nächsten Retro prüfen, ob sie erreicht sind und sinnvoll waren — Teams sollen besser, effizienter und vor allem auch glücklicher werden — "Ein heeres Ziel" (Toby, zu glücklichen Teams).

Zeitpunkt für Retrospektiven

Im Scrum Guide steht: nach dem Review, vor dem Sprint Planning — Für Retrospektiven sollte man sich genug Zeit nehmen, daher in einwöchigen Sprints vielleicht auch nur nach jedem zweiten Sprint — Retro kann auch dann stattfinden, wenn genug Themen vorhanden sind (täglich sammeln) — Retrospektiven in Kanban oder anderen Techniken ohne feste Iteration: regelmäßig einplanen — Retrospektiven kann man auch in Nicht-Software-Entwicklungs-Teams erfolgreich einsetzen — Für alle Teams, die an sich selbst arbeiten wollen — Supervision (eigentlich etwas anderes).

Rolle des Produktmanagements in der Retrospektive

Das Meeting ist für das Team, eigentlich gehört der Product Owner nicht dazu — Wenn der PO nicht disziplinarisch vorgesetzt ist, geht es problemlos — Hilft, um sehr nah am Team dran zu sein — Häufig fallen auch Aufgaben für den PO ab — Stakeholder Management — Es spricht für ein gutes Vertrauensverhältnis, wenn der PO dabei sein "darf".

Was kann schief laufen bei Sprint Reviews?

Retro ist zum Aufzeigen von Fehlern da (als Beispiel ziehen wir Review Meetings heran, da wir es in der letzten Episode vernachlässigt haben — kein Feedback von Stake Holdern — keine Stellungnahme vom Product Owner — schlechter Umgangston — Inkrement wird auf lokalem Rechner gezeigt — unfertige Ergebnisse werden präsentiert — PO kennt den Zustand nicht) .

Welche Probleme können bei der Retrospektive auftreten?

Es werden keine Maßnahmen beschlossen (oder schlechte Maßnahmen, die nicht erfüllt werden können)  — Dinge ausblenden, weil man annimmt, dass man sie nicht ändern kann — Es kann sehr emotional werden (nicht notwendigerweise schlecht oder ein Fehler)  — Man muss auch mit unangenehmen Situationen klarkommen — Emotionales auszublenden kann auch sehr schlecht sein — Teile des Teams sind nicht anwesend (bei Urlauben nicht zu vermeiden, aber es sollte nicht die Regel sein)  — Zeit zu knapp, so dass keine Maßnahmen beschlossen werden können oder Themen hintenüberfallen (der Agile Coach muss auf die Zeit achten — Drei Stunden für vierwöchige Wochen Sprints — Wenn die Sprints sehr kurz sind, kann man abwechselnd lange und kurze Retros machen)  — verschiedene Formate erfordern unterschiedlich viel Zeit — es gibt nicht nur Mad / Sad / Glad — Retromat von Corinna Baldauf.

Verabschiedung