Erstaunlich oft treffe ich in den letzten Jahren agile Teams, die zwar regelmäßig Retrospektiven (oder kurz Retros) durchführen, das aber eher unlustig und mit der mehr oder weniger unterschwelligen Einstellung, das sei Zeitverschwendung.
Nachdem ich in meinen ersten agilen Projekten mit Retros äußerst gute Erfahrungen gemacht habe, staune ich regelmäßig über eine solche Einstellung.
Irgend etwas muss hier falsch laufen. Was ist es? Und vor allem: Wie kann man Teams davon überzeugen, dass Retros nicht fruchtlos sind, sondern im Gegenteil sehr effektiv sein können?
Doch was bedeutet das, effektiv? Was ist überhaupt das Ziel von Retros?
„When we say retrospective, here’s what we have in mind: a special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork.“
Derby & Larsen, Agile Retrospectives, 2006 The Pragmatic Bookshelf, S. xv
Was läuft falsch?
Sicher gibt es viele Ursachen für Probleme mit Retros, aber ein Phänomen, das man häufig bei Teams beobachten kann, die eine eher negative Einstellung zu Retros haben, ist die Abkopplung der Retros von der eigentlichen Arbeit des Teams.
Retros werden durchgeführt, Ergebnisse werden festgehalten, Maßnahmen werden beschlossen. Dann passiert – nichts. Die Ergebnisse und Maßnahmen finden keinen Eingang in die tägliche Arbeit der Teammitglieder nach der Retro.
Das Ziel von Retros ist eine Verbesserung durch Anpassung („adapt“), das Mittel dazu ist die Überprüfung („inspect“) der bisherigen Arbeitsweise. Die Überprüfung ist das, was während der Retro passiert, die Anpassung kommt dann danach, während der täglichen Arbeit zwischen den Retros.
Was wir oft sehen, ist eine Überprüfung ohne die zugehörige Anpassung. Nur eine Anpassung der Arbeitsweise kann zu dem gewünschten Effekt der Verbesserung führen. Ohne Anpassung keine Verbesserung, kein Effekt, keine Effektivität.
Es entsteht in solchen Fällen bei den Teammitgliedern das Gefühl, sich im Kreis zu drehen, denn es wird in den Retros sehr oft immer wieder über dieselben Probleme gesprochen, aber es kommt zu keiner Lösung.
Solche Retros sind Zeitverschwendung.
„Don’t confuse motion with progress.“
Joseph Pelrine
Wie geht es besser?
Wir müssen zwei Dinge schaffen: Erstens, wir müssen anfangen, Dinge wirklich umzusetzen, die wir in der Retro beschlossen haben. Dadurch erreichen wir echten Fortschritt, bzw. echte Verbesserungen. Zweitens, wir müssen dafür sorgen, dass die Teammitglieder diese Verbesserungen auch mit der Retro in Verbindung bringen. Kurzum, wir müssen die Kluft zwischen Retro und täglicher Arbeit überwinden.
Verbesserungen wirklich umsetzen
Wie bekommen wir jetzt die beschlossenen Verbesserungen in die Umsetzung? Je nach Situation des Teams sollten wir vielleicht vorher noch einen Schritt zurückgehen und fragen: Mit welchen Verbesserungen sollten wir anfangen?
Womit beginnen?
Nach meinen Erfahrungen ist es wichtig, schnell Erfolge zu erzielen, wenn sie auch klein sein mögen. Sonst läuft man Gefahr, dass die Einstellung zur Retro so negativ wird, dass man aus dieser Situation nur noch sehr schwer herauskommt.
Es ist also sinnvoll, sich zunächst auf Quick Wins zu konzentrieren, also Erfolge, die schnell und einfach zu erreichen sind. Einfach zu erreichen sind in der Regel Veränderungen, die sich innerhalb des Teams abspielen und keine Abhängigkeiten nach außen haben. Wenn diese Änderungen dann noch wenig Aufwand verursachen, sind sie schnell zu erreichen und damit ideale Kandidaten für erste Verbesserungen.
Am besten überlegt das Team schon während der Retro, welche Verbesserungsvorschläge in die Kategorie Quick Win fallen und beschließt zunächst die Umsetzung von einem bis maximal drei dieser Quick Wins bis zur nächsten Retro.
Wider das Vergessen
Nach der Retro stürzt sich das Team normalerweise wieder auf seine tägliche Arbeit. Es ist so gut wie nie eine böse Absicht dabei, aber die Umsetzung der Ergebnisse aus der Retro fallen dabei oft dem Vergessen anheim. Wie können wir das verhindern?
Jetzt kommt es stark darauf an, wie das Team seine Arbeit strukturiert und visualisiert. Die klassische agile Arbeitsweise beinhaltet ein physisches Taskboard an einer prominenten Stelle im Teamraum. Solche Teams können von einem gleichfalls physischen Retroboard profitieren, auf dem die Ergebnisse der Retro festgehalten werden. Wenn dieses Board in der Nähe des Taskboards angebracht wird, sind die Ergebnisse immer sichtbar und werden in der Hitze des täglichen Gefechts nicht so einfach übersehen.
Noch besser ist es, Verbesserungen aus der Retro als Taskzettel direkt an das Taskboard zu bringen und in die „normale“ Abarbeitungsreihenfolge einzureihen. Um sie von den regulären Aufgaben zu unterscheiden, kann man beispielsweise eine andere Zettelfarbe verwenden oder die Zettel mit einem roten „R“ für Retro oder „Q“ für Quick Win oder auch „V“ für Verbesserung kennzeichnen. Die Möglichkeiten sind bei physischen Boards nur von der eigenen Kreativität begrenzt…
Viele Teams arbeiten nicht (mehr) mit physischen Boards, sondern nutzen ein oder mehrere Softwaretools, um ihre Aufgaben nachzuverfolgen. Bei agilen Teams ist Jira von Atlassian sehr beliebt – oder zumindest sehr verbreitet.
Mit Jira kann man mittels agiler Boards unterschiedliche Ansichten der Arbeit für ein Team erzeugen. Wenn das Team zum Beispiel für seine tägliche Arbeit ein Board hat und sich darauf Vorgänge vom Typ Story und/oder Aufgabe finden, dann kann man innerhalb weniger Minuten ein weiteres Board für die Nachverfolgung der Retro erstellen, indem man dafür andere Vorgangstypen verwendet. Theme bietet sich an für übergeordnete Ziele, die das Team erreichen will, Improvement eignet sich für konkrete Maßnahmen, die das Team beschlossen hat.
Damit hat man, nachdem man die Filterabfragen der beiden Boards auf die jeweils passenden Vorgangstypen eingeschränkt hat, zwei unabhängige Boards – eines für die Retro und eines für die tägliche Arbeit. Das ist gut für die Strukturierung, aber wir möchten ja, dass Verbesserungen in der täglichen Routine nicht untergehen, sondern sichtbar sind und umgesetzt werden.
Dafür erstellen wir für jeden Improvement Vorgang eine oder auch mehrere Unteraufgaben. Diese erscheinen dann auf beiden Boards, so dass wir immer sehen können, wo wir mit unseren Verbesserungen stehen.
Rechnung mit einer Unbekannten
So weit so gut. Wir haben die Voraussetzungen geschaffen, um aus der Retro heraus (zunächst) im Team die möglichen Verbesserungen („inspect“) auch wirklich in die Realität zu überführen („adapt“).
Wir müssen eins dabei auf jeden Fall vermeiden: Die Rechnung ohne den Wirt zu machen. Irgend jemand bezahlt für die Dinge, die ein agiles Team tut. In Scrum heißt die Rolle Product Owner. Diese Bezeichnung schwappt in den letzten Jahren auch in andere Bereiche über und wird langsam zu einem Synonym für die Geschäftsseite.
Deshalb: Wir müssen den Product Owner mit ins Boot holen, denn alles was wir bisher getan haben, funktioniert nicht, wenn die Geschäftsseite unsere Verbesserungsmaßnahmen immer wieder herunterpriorisiert und damit auf den St. Nimmerleinstag verschiebt. Hier ist das ganze Team gefragt, aber insbesondere der Scrum Master oder agile Coach, um das zu verhindern.
Natürlich gibt es immer ein Feature, das wichtiger ist als alles andere, aber mindestens eine Verbesserung zwischen zwei Retros muss möglich sein – sonst können wir uns die Retro gleich selbst sparen.
Erfolge feiern
Wir haben also alles richtig gemacht: Wir haben Quick Wins identifiziert, wir haben dafür gesorgt, dass sie nach der Retro nicht vergessen werden, wir haben sie mit dem Product Owner zusammen eingeplant, umgesetzt – und jetzt?
Es reicht manchmal nicht aus, dass sich etwas objektiv verbessert. Wir müssen auch dafür sorgen, dass die Erkenntnis darüber in der subjektiven Wahrnehmung der Beteiligten ankommt.
Aus meiner Erfahrung heraus geschieht das am besten im Zusammenhang mit der Veranstaltung, in der auch das Ergebnis der regulären Arbeit am Produkt begutachtet wird. In Scrum wäre das der Sprint Review, in Kanban der Operations Review. In diesen Terminen haben wir den weiteren Vorteil, dass nicht „nur“ das Team anwesend ist, sondern auch wichtige Stakeholder, nach dem Motto: „Tue Gutes und rede darüber“.
Gibt es keine solche Veranstaltung, sollte zumindest am Anfang der nächsten Retro auf die Ergebnisse der vorherigen Retro Bezug genommen werden.
Fazit
Mit wenigen kleinen Änderungen an der Retro und der Verbindung der Ergebnisse mit der täglichen Arbeit können wir erreichen, dass in eine festgefahrene Teamsituation wieder Bewegung kommt und wieder echte Verbesserungen der Zusammenarbeit möglich werden – Bereitschaft zur Veränderung vorausgesetzt.
Fangt mit den Quick Wins an und sorgt dafür, dass sie im täglichen Chaos nicht untergehen. Danach können wir uns an die größeren Aufgaben wagen – und das Team kann über sich hinauswachsen.
Hab ich schon gesehen – hab ich schon gemacht.
