© S&S Media
Lebendige Retrospektiven ohne Routine

Immer neu statt wie immer


Die Retrospektive ist ein fester Bestandteil der agilen Softwareentwicklung und dient nicht nur dazu, flexibel und dynamisch auf Anforderungsänderungen reagieren zu können, sondern auch die eigene Arbeitsweise stetig zu verbessern. Nach dem dritten Projekt oder fünfzehnten Sprint in gleicher Teamzusammensetzung macht sich aber selbst beim erfahrensten „Agilisten“ Routine breit. Diesen Moment gilt es rechtzeitig zu erkennen und gegenzusteuern.

Dem Scrum-Prinzip „Inspect and Adapt“ folgend, untersuchen die meisten agilen Entwicklungsteams am Ende des Sprints in der Retrospektive ihre Arbeitsmethoden und versuchen anhand von Erfolgen und Misserfolgen, nötige Maßnahmen abzuleiten, um im Folgesprint bessere Bedingungen für sich und das Produkt zu schaffen. Soweit zumindest die Theorie, denn in der Praxis hört man immer wieder, dass sich in der Regel doch nichts ändert. So zeigte eine während eines Vortrags durchgeführte Umfrage [1] auf den Magdeburger Developer Days 2017, dass zwar 98 Prozent der Teilnehmer eine Retrospektive durchführen, aber lediglich 75 Prozent einen Nutzen daraus ziehen.

Einer der Gründe mag sein, dass viele Teams mit der Zeit in eine Routine verfallen und die Retrospektive unbewusst zu einem statischen Teil des agilen Prozesses verkommt. Nach dem Motto „sie findet halt statt und man redet ein bisschen über die vergangenen Wochen“. Mittlerweile gibt es diverse alternative Ansätze zur klassischen Methode, auf die im Laufe des Artikels eingegangen wird. Doch ehe man als Scrum Master nun sein Pulver leichtfertig verschießt und dennoch nicht den gewünschten Effekt erzielt, empfiehlt es sich, zunächst den Kern des Problems aus einem anderen Blickwinkel zu betrachten.

Das Problem mit dem Feedback

In der Retrospektive geht es vor allem um Feedback – Feedback zu geben, aber auch Feedback zu erhalten; nicht nur zu inhaltlichen oder prozessbezogenen Problemen, sondern auch zu zwischenmenschlichen. Wenn man in Wikipedia Feedback nachschlägt [2], erhält man eine sachliche, trockene Definition, bei der man sich mit einem inneren Schmunzeln nicht wundern darf, warum wir Deutschen im Ausland nicht gerade für unsere Feedbackkultur bekannt sind. Unabhängig von kulturellen Unterschieden in diesem Zusammenhang, erhält der ursprüngliche Sender einer Nachricht durch das Feedback seines Gegenübers dabei Informationen darüber, was „der Empfänger wahrgenommen bzw. verstanden hat“, und kann gegebenenfalls ein Missverständnis rechtzeitig aufklären und klarstellen.

Gerade beim Timing des Feedbacks gehen aber viele Teams den Weg des geringsten Widerstands, und so fällt häufig der Satz „das ist ein Thema für die Retrospektive“. Aber warum warten und Zeit verstreichen lassen? In der agilen Entwicklung sollte jedes Meeting als Gelegenheit für einen Austausch verstanden werden, angefangen vom Kick-off-Meeting, dem ersten offiziellen Termin zum Start der Projekt- bzw. Produktentwicklung. So ist es mehr als empfehlenswert, wenn es um die Erläuterung der Produktvision geht, alle Beteiligten an einem Tisch zu versammeln. Dies schließt neben dem Product Owner und dem Entwicklungsteam die Konzepter, Designer, Tester und natürlich auch die Stakeholder mit ein. Sollte es unterschiedliche Ansichten über die Ausrichtung des Produkts oder z. B. technische Bedenken zur Realisierung geben, so sind diese möglichst früh aufzudecken. Denn wie im klassischen Projektmanagement gilt auch hier, dass die Kosten für die Korrektur steigen, je später das Problem identifiziert wird.

Dieser offene und regelmäßige Austausch lässt sich in etwas abgewandelter Form selbstverständlich auch auf die anderen Meetings des agilen Prozesses anwenden. So werden zwar häufig im Planning II (oder alternativ Architecture Session) noch die im Sprint geplanten Stories in Subtasks unterteilt, über den Lösungsansatz selbst wird aber weit seltener diskutiert. Dies hatte schon wiederholt zur Folge, dass erst im Codereview – nach mehreren Tagen Arbeit an einer größeren Story – die Frage gestellt wurde, warum der umsetzende Entwickler denn z. B. die Nutzerdaten in eine JSON-Datei persistiert und nicht in eine Datenbank wie SQLite. Die Antwort mag einfach wie auch verständlich erscheinen: Damit kannte er sich aus. Der PO wird dagegen alles andere als glücklich über den Zeitverlust sein, sollte SQLite doch die bessere Entscheidung gewesen sein und wird vermutlich fragen, warum sich das Team denn ni...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang