Ein Retro-Thema, das dreimal auftaucht, gehört nicht mehr in die Retro

Retro-Time und mal wieder geht es um die offene Entscheidung des Managements, ob wir im Sprint releasen dürfen oder erst am Ende. Erstaunlich, dass überhaupt jemand aus dem Team noch die Kraft hat, das Post-it zu schreiben.

Wenn ein Thema zum dritten Mal als Post-it am Whiteboard klebt, hat die Retro es nicht gelöst und beim vierten Mal wird sie es auch nicht lösen. Dafür gibt es nach meiner Erfahrung genau zwei Gründe. Entweder hat das Team nie ein Action Item aufgenommen und auf das Board gepackt, oder das Thema liegt gar nicht beim Team: eine Entscheidung im Management, eine Vorgabe aus der Firma, die für eure Arbeit keinen Sinn ergibt, ein anderes Team, auf das ihr wartet.

In der Retro sehen beide Gründe gleich aus. Dieselben Stickies, dasselbe Seufzen. Sie brauchen aber verschiedene Antworten, deshalb wird zuerst sortiert.

Erste Frage: Gab es ein Action Item?

Schaut in die letzten drei Retros. Habt ihr Action Items aufgenommen? Steht ein Name dran? Hat in der Retro danach irgendwer gefragt, was daraus geworden ist?

Wenn nicht, ist die Sache einfach, aber unbequem. Ihr habt das Thema besprochen und dann liegen lassen. Was das kostet, habe ich in Deine Retro: 1.200 € für die Tonne? vorgerechnet. Die Kurzfassung: Das Action Item kommt als normales Ticket mit Assignee aufs Board, und die nächste Retro beginnt mit der Frage, ob es erledigt ist.

Für den zweiten Grund reicht das nicht.

Zweite Frage: Könnt ihr das überhaupt lösen?

Viele Retro-Themen haben ihre Ursache außerhalb des Teams. Freigaben, die Tage dauern. Ein Budget, das jemand anderes verwaltet. Eine Regel, die für alle Teams gilt, egal wie deren Arbeit aussieht.

Dafür kann das Team kein Action Item schreiben, das es selbst abarbeitet. Also schreibt es keins. Das Thema landet wieder auf dem Whiteboard, die Leute werden zynischer, und irgendwann sitzt das Team nur noch da und meckert über „die da oben“.

Ein bekanntes Retro-Format teilt Themen in drei Kreise: was das Team selbst ändern kann, was es beeinflussen kann, und den Rest, die „Suppe“, die es hinnehmen muss. Das Sortieren hilft. Der übliche Rat dazu hilft nicht: „Konzentriert euch auf das, was ihr ändern könnt.“ Das klingt vernünftig und läuft am Ende darauf hinaus, dass niemand das Problem je zu der Person bringt, die es lösen könnte.

Beeinflussen heißt übergeben

Für ein Thema im mittleren Kreis sieht das Action Item anders aus. „Wir sprechen nochmal mit dem Management“ zählt nicht. Das Action Item heißt: Wer bringt das Thema bis wann zu wem, der darüber entscheiden darf?

Ins Ticket gehören damit drei Dinge. Ein Name aus dem Team, oft der Scrum Master. Ein Empfänger, der wirklich entscheiden darf, nicht der nächstbeste Vorgesetzte. Und eine Frage, die man mit Ja oder Nein beantworten kann. „Wir wollen öfter releasen“ ist keine Frage. „Darf das Team im Sprint releasen, sobald eine Story fertig und getestet ist?“ ist eine.

Der Scrum Guide sagt, der Scrum Master soll die Beseitigung von Hindernissen bewirken. Genau das ist diese Übergabe.

Dann kommt der Teil, der fast immer fehlt: die Antwort. Die nächste Retro fragt, was aus der Übergabe geworden ist, und wenn noch keine Antwort da ist, fragt das Team beim Empfänger nach, gern schriftlich und mit Datum.

Warum die Antwort so wichtig ist, steckt in der Work–Feedback Loop. Ein Signal, das alle sehen, das aber keine Entscheidung auslöst, heißt dort Entscheidungs-Latenz. Das Team arbeitet weiter, die Organisation lernt nichts dazu. Jede Retro, in der das Thema wiederkommt, ist ein weiterer Tag auf diesem Zähler.

Ein Nein ist eine Antwort

Manchmal sagt das Management Nein. Die Vorgabe bleibt, das Budget kommt nicht. Das ist ärgerlich, aber es ist ein Ergebnis. Ab jetzt liegt das Thema im äußeren Kreis. Das Team kann damit umgehen: einen Workaround bauen, Erwartungen an Kunden anpassen, oder einfach wissen, woran es ist.

Und dann fliegt das Thema von der Retro-Liste. Bewusst, mit einem Satz im Protokoll: „Übergeben am 3. März, Antwort Nein, wir arbeiten damit.“ Wer es in einem halben Jahr wieder aufmachen will, weil sich etwas geändert hat, darf das. Aber nicht jede zweite Woche aus Gewohnheit.

Schlimmer als ein Nein ist Schweigen. Dann hängt das Thema weiter im Raum, und das Team lernt, dass Retros nichts bringen.

Die Drei-Mal-Regel

Probiert in den nächsten Retros eine Regel aus. Kommt ein Thema zum dritten Mal, wird es nicht mehr diskutiert. Ihr stellt nur zwei Fragen. Gibt es ein Action Item, das jemand angeht? Wenn nein, schreibt eins, mit Namen. Kann das Team das Thema selbst lösen? Wenn nein, schreibt eine Übergabe: wer, an wen, welche Frage, bis wann.

Nach drei Monaten wisst ihr, welche Themen eure Retro blockieren, bei wem sie liegen und wie lange ihr jeweils auf eine Antwort gewartet habt. Das wissen viele Teams nicht mal nach drei Jahren.

Feedback oder Widerspruch? Schreib mir auf Mastodon an @nobsagile oder per Mail an nobsagile@gmail.com.