„Bisher sind wir doch auch ohne klargekommen“; „Können wir uns die Zeit nicht sparen?“; „Bringt uns das wirklich weiter?“ – Bei der Umsetzung konkreter agiler Arbeitsstrukturen werden oft Vorbehalte laut. Dabei bilden auch Retrospektiven keine Ausnahme. Unter dem Vorwand, Zeit zu sparen, werden sie immer wieder ausgesetzt oder gleich ganz gestrichen. Ein folgenreicher Fehler. Denn der vermeintlich eingesparten Arbeitszeit stehen Ressourcenverschwendung und Unzufriedenheit im Entwicklungsteam gegenüber.
Regelmäßige Retrospektiven hingegen lösen Probleme, steigern Vertrauen, Verantwortlichkeit und Zielausrichtung im Team und können dadurch sowohl die Performance als auch die Qualität des Produktes verbessern.

Welchen Sinn haben Retrospektiven?

Agile Teams zeichnet nicht nur eine höhere Flexibilität bei der Bewältigung anstehender Aufgaben aus, sondern auch eine hohe Innovationsbereitschaft. Damit die Zusammenarbeit gut funktionieren kann, sind agile Teams auf regelmäßige Reflexion der gemeinsamen Arbeitsweise angewiesen. Genau dazu bieten Retrospektiven eine zuverlässige Basis. Sie erzeugen gegenseitiges Verständnis, ermöglichen kollektive Lernprozesse, stoßen Veränderungen an und lenken Handlungen in eine gemeinsame Richtung. Im agilen SCRUM-Framework finden Retrospektiven am Ende jedes Sprints statt, das Framework und der zeitliche Abstand sind aber nicht entscheidend. Wichtig ist dagegen die Regelmäßigkeit der Treffen, um eine kontinuierliche Verbesserung der Zusammenarbeit zu erreichen.

Welche Chancen bieten Retrospektiven? – 6 Beispiele aus dem Projektalltag

Die größte Gefahr für den Erfolg jedes Teams ist fehlende oder mangelhafte Kommunikation. Denn ohne einen guten gemeinsamen Austausch leidet auch das Verständnis füreinander, Unklarheiten entstehen, Prozesse werden ineffizienter. Das führt nicht nur zu erheblichen Kostensteigerungen, sondern auch zu Unzufriedenheit und zu unausgesprochenen Konflikten. Retrospektiven sind ein Ankerpunkt für den Austausch, die Auseinandersetzung und die gemeinsame Orientierung im Team, der negativen Entwicklungen entgegenwirkt. Wie dies in der agilen Praxis aussieht, möchte ich anhand der folgenden 6 Beispiele zeigen:

1. Verbesserte Produktivität: Immer wieder schleichen sich in Teams Arbeitsweisen ein, die zwar für die individuellen Entwickler*innen sinnvoll erscheinen, für das gesamte Team im aktuellen Projekt aber nicht zielführend sind.
   In der Remote-Arbeit kann beispielsweise die räumliche Distanz dazu führen, dass der Austausch zur Arbeitsteilung „über den Schreibtisch hinweg“ fehlt und größere Aufgaben daher von einzelnen Personen erledigt werden, denen dieses Vorgehen effizienter erscheint, weil sie dadurch die anderen in ihrem Arbeitsfluss nicht stören. Allerdings bleiben Anforderungen dabei insgesamt länger in Bearbeitung. Die Retrospektive schärft den Blick des Teams auf solche Produktivitätsverluste und ermöglicht die gemeinsame Entwicklung neuer Methoden der Kollaboration. Die verbesserte Arbeitsteilung steigert Performance und Produktivität.
   
   
2. Verbesserter Wissenstransfer: Fehlen Menschen Informationen, so bindet die Informationsbeschaffung nicht nur Kapazitäten der Informationssuchenden, sondern häufig auch der Teammitglieder, die im Besitz der Informationen sind. Wenn mehrere Mitarbeitende ein Teammitglied kontaktieren, weil sie eine Einstellung in der Software nicht verstanden hatten, muss dieselbe Information wiederholt weitergegeben werden, was den Workflow unterbricht und erhebliche Ressourcen bindet. In der Retrospektive kann die Thematik besprochen und ein gemeinsamer Workshop zur Vermittlung der Informationen geplant werden.
   
   
3. Verbesserte Qualität: Besteht unzureichender Kontakt zwischen Entwicklungsteam und Kunden, kann dies schnell zu Missverständnissen und Unzufriedenheiten führen. Denn dem Team fehlen Informationen, um die gewünschte Lösung umzusetzen.
   In der Retrospektive kann dieses Kommunikationsdefizit analysiert und die notwendigen Informationen eingefordert werden: Product Owner, Scrum Master oder Projektleiter werden aufgefordert, den Informationsaustausch zu intensivieren. In regelmäßigen Abständen werden die Fortschritte in den Retros evaluiert. Die Folge: ein besseres Produkt, ein zufriedenerer Kunde und ein weniger frustriertes Entwicklungsteam.
   
4. Verbesserte Volumina: Ein ehrgeiziger Zeitplan ist gut, ein zu ehrgeiziger Zeitplan nicht. Es entsteht erheblicher Druck, wenn der Kunde ein Feature bereits ankündigt, bevor die Ressourcen für den Entwicklungsprozess genau abgeschätzt werden konnten. Das noch nicht finalisierte Feature muss dadurch verfrüht auf die Produktivumgebung geschoben werden. Der Testaufwand und die Anzahl der Bugs steigt, wodurch weitere Kapazität im Team gebunden wird. Der Rückstand zum ursprünglichen Zeitplan vergrößert sich weiter. In der Retrospektive kann eine Analyse der Timeline die entsprechenden Zusammenhänge verdeutlichen. Für zukünftige Releases können dadurch passendere Zeitabschnitte festgelegt werden.
   
   
5. Verbesserte Zusammenarbeit und Zufriedenheit: Grundsätzlich kann davon ausgegangen werden, dass jedes Teammitglied gute Arbeit leisten möchte. Allerdings kann das Verständnis, was gute Arbeit eigentlich ist, mitunter sehr verschieden sein. So wünschen sich manche Mitarbeitenden einen intensiveren Austausch über die Zusammenarbeit, während andere lieber für sich arbeiten. Einige Teammitglieder legen mit der Erledigung ihrer Aufgaben direkt los, andere überlegen erst intensiv, wie sich ihre Handlungen auf andere auswirken. So kommt es nicht selten vor, dass viele individuelle Entscheidungen – alle inspiriert von dem Anspruch, gute Arbeit zu leisten – dennoch zu Unzufriedenheit und negativen Auswirkungen für das Miteinander führen. In der Retrospektive können diese Unterschiede besprochen werden. So wird Vertrauen aufgebaut. Das hat nicht nur zufriedenere Mitarbeiter*innen zur Folge, sondern auch verbesserte Prozesse.
   
   
6. Verbesserte Partizipation: Verändert man das System, wie Menschen miteinander kommunizieren, so verändert man den gesamten Entwicklungsprozess. Das Verändern der Kommunikation ist also eine gute Möglichkeit, um mehr Partizipation im Team zu ermöglichen. In fachlich orientierten Meetings ist dies jedoch nicht immer möglich, alle Beteiligten unabhängig von ihrem Wissensstand gleichermaßen miteinzubeziehen – im Gegensatz zu Retrospektiven. Denn diese bieten gute Möglichkeiten, ruhige oder weniger erfahrene Personen durch kollaborative Gestaltungsmethoden und eine gute Moderation zu motivieren, ihre Ideen in den Entwicklungsprozess einzubringen. So kann brachliegendes Potenzial aktiviert werden, um gemeinschaftlich mehr Ansätze für die Lösung von Problemen zu finden.

Retrospektiven – eine Investition, die sich auszahlt

Laut einer Studie des Zeitplanungssoftware-Anbieters Clockwise verbringen Softwareentwicklerinnen und -entwickler bis zu 11 Stunden pro Woche in Meetings. Die Motivation, die Notwendigkeit von Meetings kritisch zu hinterfragen, ist daher ebenso sinnvoll wie verständlich. Allerdings zeigen die oben genannten Beispiele, dass die Überlegung, die Zeiten für Meetings durch die Reduzierung oder das Aussetzen von Retrospektiven einzusparen, alles andere als effizient ist. Denn gerade Retrospektiven sind ein Garant dafür, dass die Mitglieder des Entwicklungsteams ihre wertvolle Arbeitszeit nicht in Nebenschauplätze investieren müssen, sondern langfristig effektiv und zielorientiert einsetzen können. Die „Retrozeit“ ist daher die wahrscheinlich am besten investierte Arbeitszeit für jedes Entwicklungsteam. Retrospektiven sorgen nicht nur für effizientere Entwicklungsprozesse, sondern auch für mehr Zufriedenheit im gesamten Team.