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 (Eigene, nicht zwingend repräsentative Umfrage während des Vortrags „Agile Feedbackkultur“) 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, 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 nicht vorher besser abgestimmt hat. Wäre in der Architecture Session bereits über Lösungswege gesprochen worden, wäre durch offenes Feedback vermutlich früher aufgefallen, dass das Team noch kein einheitliches Verständnis zur Persistenz der Daten hat und somit unnötigen Zeitverlust hätte vermeiden können.

Wo fachliche Unterschiede noch relativ schnell zu erkennen sein mögen, wird es bei kulturellen Unterschieden deutlich schwieriger. Gerade in internationalen gemischten Teams prallen hier teilweise Welten und Weltanschauungen aufeinander, die weder auf den ersten noch auf den zweiten Blick direkt zu erkennen sind. Während man den Deutschen noch nachsagt, ihre Meinung stets direkt und schonungslos mitzuteilen, neigen z. B. Menschen aus dem asiatischen Raum eher zur Zurückhaltung und Höflichkeit, was zu grundlegenden Missverständnissen im täglichen Umgang führen kann, wenn die kulturellen Unterschiede bei der Art des Feedbacks nicht berücksichtigt werden. Da nicht jeder mit seinen Arbeitskollegen abends auf ein Bier gehen möchte, der Austausch außerhalb des Büros aber dazu beitragen kann, ein besseres Gefühl für die Art des jeweils anderen zu bekommen, bietet sich hier ein regelmäßiger Teamlunch an. Man kann z. B. die Retrospektive und das Planning so legen, dass dazwischen Zeit für das Team bleibt, einmal im Sprint gemeinsam mittags essen zu gehen.

NEWSLETTER

Alle News zu Web Design, UX und Digital Marketing

Leave this field empty if you're human:

Tapetenwechsel

Bei einigen Projektteams dauert es länger, bei anderen kürzer, aber irgendwann machen sich gewisse Ermüdungserscheinungen bei der Retrospektive im Stile von Mad, Sad, Glad breit (Abb. 1). Häufig zeigt sich dies in geringerer Motivation oder zurückgehender Teilnahme der einzelnen Personen. Das Feedback muss regelrecht herausgekitzelt werden oder beschlossene Maßnahmen aus dem vorherigen Sprint werden seltener umgesetzt. Erfahrene Teams und Scrum Master können innerhalb des gewohnten Vorgehens mit Variationen der Fragestellungen gegensteuern. Bei gemischten oder unerfahreneren Teams hat sich jedoch ein kompletter Tapetenwechsel häufig als die beste Lösung erwiesen.

Dabei gilt es zunächst zu verstehen, was genau die Ermüdung ausgelöst hat. Ist es die Länge des Termins zum Abschluss des Sprints? Oder nimmt sich das Team einfach zu viele Maßnahmen vor? Kommt im Grunde am Ende des Sprints immer nur das gleiche Feedback, wie gut man doch zusammenarbeitet, wie toll die Kommunikation ist und dass nun alles viel besser läuft – obwohl das Sprintziel dennoch ein weiteres Mal nicht erreicht wurde? Im Folgenden werden alternative Ansätze erläutert, die eine Lösung für die drei zuvor beschriebenen Probleme darstellen können.

Die Lightning Retro

Ausgangslage ist ein Team, das im Großen und Ganzen funktioniert und auch keine Probleme mit der Kommunikation hat. Nach einem manchmal nervenaufreibenden Sprint ist die Retrospektive zu einer zähen Diskussion verkommen, in der auch mal das Gefühl aufkommt, sich im Kreis zu drehen oder zu Tode zu debattieren. Andere Teammitglieder haben sich längst aus dem Gespräch rausgezogen und verfolgen mehr oder weniger aufmerksam das argumentative Hin und Her der Rädelsführer. Natürlich ist dies eine überspitzte Darstellung, aber wenn man ehrlich ist, saßen vermutlich die Meisten schon in einer Retrospektive, deren Ende man sich lieber früher als später herbeigesehnt hat.

In Anlehnung an Lightning Talks bekommt bei dieser Alternative zum klassischen Modell jeder Teilnehmer eine zeitlich begrenzte Redezeit von wenigen Minuten, in denen er seine Top 5 des Für und Wider über den Sprint zusammenfasst. Das Team entscheidet in einer kurzen Abstimmung, welche dieser Punkte allgemein gültig sind und für welche Maßnahmen man Action Points ableiten muss. Bei einem verteilten Team kommt man nicht daran vorbei, diese To-dos digital in einem Wiki wie z. B. Confluence zu erfassen. Sitzt das Team lediglich an einem Standort, empfiehlt es sich, pro Maßnahme einen Klebezettel zu erstellen, der dann so platziert wird, dass er bei jedem Daily Scrum sichtbar ist. Dadurch wird gewährleistet, dass die geplanten To-dos nicht während des Sprints vergessen werden. Ziel der Lightning Retro ist die Fokussierung auf das Wesentliche.

30-Minute Retrospective

Ähnlich zur Lightning Retro geht Philip Rogers in seiner „30-minute retrospective“ vor. Dieser Ansatz richtet sich an erfahrenere Teams, die aber wiederum dazu neigen können, sich zu viele Maßnahmen für den Folgesprint vorzunehmen. Im Zentrum der Retrospektive stehen die nachfolgenden vier Fragen:

• Was wollen wir verwerfen?
• Was müssen wir hinzufügen?
• Was sollten wir behalten?
• Was können wir verbessern?

Nach der üblichen Einleitung und Begrüßung durch den Scrum Master nimmt sich jeder Teilnehmer fünf Minuten Zeit, für jede dieser Fragestellungen mindestens eine Antwort zu finden und auf einen Klebezettel zu schreiben. Nach Ablauf der Zeit werden alle Zettel auf einem Whiteboard angeordnet – und zwar auf einem vorbereiteten Koordinatenkreuz in ihren zugehörigen Quadranten (Abb. 2). Zur besseren Visualisierung können unterschiedlich farbige Klebezettel je Bereich verwendet werden. Das Team kommt im Anschluss am Whiteboard zusammen und gruppiert mögliche Duplikate, in dem diese Zettel übereinander geklebt werden.

Im anschließenden Teil der Retrospektive mit einer Dauer von zehn Minuten entscheiden sich die Teilnehmer für einen der vier Quadranten und stimmen darüber ab, an welchen der auf den Zettel notierten Punkte sie im nächsten Sprint arbeiten möchten. Dieses Vorgehen wird für einen weiteren Quadranten wiederholt und liefert somit dem Team die beiden wichtigsten Herausforderungen, die sie als Nächstes angehen wollen. Gemeinsam werden nun analog zur Lightning Retro die Maßnahmen inklusive Verantwortlichem definiert, um die beiden wichtigsten Punkte auch umzusetzen.

Da jeder Teilnehmer sein Feedback zunächst für sich notiert, wird mit dieser Methode sichergestellt, dass sich niemand gegenseitig beeinflusst oder unter Umständen wichtige Punkte von stilleren Personen nicht auf den Tisch kommen. Weiterhin wird nicht nur darauf geschaut, was schlecht lief oder verbessert werden sollte, sondern auch was gut lief und z. B. dringend beibehalten werden muss. Ein Risiko ist dagegen, aufgrund der Begrenzung auf die beiden wichtigsten Punkte sowie Beschränkung auf zwei Quadranten pro Retrospektive, dass kritische Themen aufgeschoben werden. Der Vorteil des geringen Zeitaufwands wird so unter Umständen teuer erkauft. Daher ist dieses Vorgehen erfahrenen Teams zu empfehlen, die genug Flexibilität besitzen, situationsbedingt noch einen dritten oder vierten Punkt zur Diskussion zu stellen.

Die Retrospektive als Geschichte

Nachdem die beiden vorherigen Ansätze sich eher für erfahrenere oder kommunikativere Teams eignen mögen, soll zum Schluss noch eine Methode vorgestellt werden, die auch stilleren und unerfahreneren Teilnehmern ihr Feedback entlocken soll. Dies mag vielleicht am einfachsten gelingen, wenn man weit genug vom klassischen Pfad abweicht und für kurze Zeit eine alternative, fiktive Welt schafft. Dazu bedient man sich einer Bildersprache um eine Geschichte zu erzählen, die tendenziell auch Kritik offen formulieren kann, ohne verletzend, sondern stattdessen konstruktiv zu wirken. Um nicht auf der grünen Wiese zu starten und am Ende völlig unterschiedliche Erzählungen zu erhalten, kann man sich Hilfsmitteln wie Story Cubes bedienen. Dabei handelt es sich um gewöhnliche Würfel, die jedoch statt Zahlen Symbole auf allen Seiten haben (Abb. 3). Diese Zeichen sind bekannte Gegenstände aus dem Alltag wie eine Uhr, ein Telefon oder ein Bierkrug.

Zu Beginn der Retrospektive wird gewürfelt und anschließend hat jedes Teammitglied zehn Minuten Zeit, aus demselben Würfelergebnis eine Geschichte zu formulieren, die seine persönlichen Erlebnisse des gerade abgeschlossenen Sprints beschreiben. Die Symbole sollen dabei die Kreativität jedes einzelnen anregen. Und obwohl alle auf die gleichen Würfel schauen, werden sich die Geschichten dennoch unterscheiden, da jeder mit den Bildern etwas anderes im Rahmen seiner Erzählung assoziiert. Während ein Flugzeug bei einer Person z. B. für Geschwindigkeit stehen kann, verbindet vielleicht jemand anderes damit herausragende Ingenieurskunst, und der Nächste denkt womöglich nur an Pilotenstreiks. Nach Ablauf der Zeit hat jeder Teilnehmer zwei Minuten Zeit, seine Geschichte vorzutragen. Dabei sollte es auch erlaubt sein, die vorbereitete Erzählung abzulesen, um auch introvertierten Personen oder internationalen Teammitgliedern mit möglichen Sprachbarrieren, Hemmungen vor dem freien Sprechen zu nehmen. Wie bei der Lightning Retro sollten im Anschluss auf Basis der vorgetragenen Erzählungen Maßnahmen identifiziert und auf Klebezetteln oder im Wiki notiert werden. Hierbei zeigt die Praxis, dass durch die Verwendung von Bildersprache das Feedback häufig bewusster aufgenommen und daher besser gemerkt werden kann.

Wie der Einsatz von Story Cubes in der Praxis aussehen kann, soll das nachfolgende Szenario veranschaulichen. Auf Basis des fiktiv gewürfelten Beispiels aus Abbildung 3 könnte ein Teammitglied folgende kurze Geschichte erzählen:

• Wir haben alle kritischen Bugs unserer Mobile-App beseitigt und rechtzeitig den drohenden Brand vermieden.
• Für den weltweiten Roll-out werden wir jedoch einige Nachtschichten benötigen.
• Das Team ist zwar stolz auf das Ergebnis, leidet aber stark unter dem Druck des Managements und hat zu wenig Klarheit über die nächsten Ziele

Der hier erzählende Teilnehmer beschreibt in seiner Geschichte, was gut lief und welcher Einsatz dafür nötig war. Aus dem positiven Feedback lässt sich daher auch eine Lehre ziehen. In diesem Beispiel waren die Softwarebugs offenbar geschäftskritisch. Aber hätten sie vorab vermieden werden können? Kann das Team nun Maßnahmen ableiten, damit sich dies in Zukunft nicht wiederholt? Darüber hinaus äußert der Erzähler eine Sorge für die weiteren Sprints. Die Arbeitslast aufgrund des nahenden Roll-outs scheint so groß zu sein, dass das bestehende Team nur mit Nachtschichten dagegen ankommt. Sollte diese Einschätzung bestätigt werden, wurde hier rechtzeitig die Hand gehoben, um Maßnahmen zu ergreifen, ehe der Schaden entsteht. Kann man vielleicht den weltweiten Roll-out in kleinere Phasen unterteilen und verschiedene Länder der Reihe nach launchen? Oder Teile der Arbeit auf andere Teams verteilen? Zu guter Letzt wird eine klare Kritik am Management geäußert, die aber wertvolles Feedback enthält. So ist dem Erzähler offenbar nicht immer klar, warum er bestimmte Aufgaben erledigen soll. Wer aber nicht weiß, warum er etwas tut, handelt meist nicht im Sinne des Produkts und ist auch nicht in der Lage, rechtzeitig und proaktiv Probleme aufzuzeigen.

Öfter mal was Neues

Auch wenn die klassische Retrospektive für viele Projektteams vermutlich vollkommen ausreichend erscheinen mag, sollte man regelmäßig einen Schritt zurücktreten und nach Anzeichen für Ermüdungserscheinungen in der täglichen Ausführung, monotone Prozesserfüllung oder ineffiziente Routine Ausschau halten. Da sich trotz Scrum manche Menschen mit Veränderungen schwertun, muss man hier behutsam die bestmöglichen Methoden abwägen. Statt gleich das ganze Vorgehen der Retrospektive zu ändern und damit vielleicht mehr Schaden als Nutzen anzurichten, lässt sich auch im Kleinen anfangen und die anderen Meetings im agilen Entwicklungsprozess wie eingangs beschrieben besser für Feedback und Austausch nutzen. Hat man damit Vertrauen im Team geschaffen, wächst häufig auch die Bereitschaft für größere Schritte, einfach mal etwas auszuprobieren, getreu dem Motto „öfter mal was Neues“. Denn schließlich lehrt uns Scrum, es im Bedarfsfall erneut anzupassen, wenn nicht die gewünschten Verbesserungen erzielt wurden.