Die Retrospektive ist eine elementare Zeremonie von Scrum. Mittels der Retrospektive können Potenziale eines Teams identifiziert und anschliessend aktiviert werden. Die Ernsthaftigkeit und Beflissenheit einer Retrospektive belegen das Qualitätsbewusstsein eines Teams. In diesem Beitrag zeigen wir, wie der team.tschegg (vormals: dot.benchmark) die Retrospektive unterstützt, weil durch den team.tschegg Fakten geliefert werden.
Agilität ist kein starrer Zustand, Agilität ist vielmehr das fortwährende Streben nach einem "besseren Team", nach einer besseren Organisation - Agilität ist in letzter Konsequenz Qualitätsmanagement. Agilität kennt keinen Zielzustand. Die Retrospektive als Werkzeug hat sich in den meisten agilen Teams etabliert, das belegen unsere internen Auswertungen basierend auf den anonymisierten Daten des team.tschegg.
Doch - und hier kommt das grosse "aber" - das Qualitätsmerkmal einer Retrospektive ist nicht "wir haben es durchgeführt". Viel wichtiger als das blosse Stattfinden sind natürlich Ablauf und Inhalt und schlussendlich die Wirkung auf den Zusammenarbeitsprozess, der durch die Retrospektiven kreiert wird. Bleibt dies aus, so ist dieses Ritual fades Beiwerk und könnte genauso gut ersatzlos gestrichen werden.
Wie funktionieren Retrospektiven? Um es kurz zu machen, folgen Retrospektiven den folgenden fünf Schritten:
Trotz dieses Ablaufs und unserer Tipps, haben Retrospektiven, gerade im Dauereinsatz, auch ein paar Probleme, die hier aufgezeigt werden sollen. Wichtiger aber noch: Wir zeigen ebenfalls, wie man diese Probleme adressieren und damit umgehen kann.
Geübte Teams praktizieren nicht zum ersten Mal eine Retrospektive. Die hundertste Retrospektive kann das Team möglicherweise ermüden. Das ist normal. Leider sinkt damit aber auch oftmals die Qualität der Retrospektiven. Der Scrum Master muss nun Muster brechen, das Team auflockern und dadurch neue Erkenntnisse, sowie Massnahmen schöpfen. Dieser Musterbruch kann zum einen natürlich durch die Wahl von verschiedenen Techniken, sowohl beim Check-In als auch bei der Datensammlung, sowie beim Erzeugen von Erkenntnissen erfolgen. Ein erfahrener Scrum Master hat deshalb immer ein Arsenal an verschiedenen Werkzeugen zur Hand, welches er dann situativ einzusetzen weiss. Hier zeigen wir euch ein paar Beispiele, wie eine Retrospektive abwechslungsreich gestaltet werden kann.
Das Ziel einer Retrospektive ist es, Massnahmen zur Verbesserung der Zusammenarbeit zu erzeugen. Doch wie kann garantiert werden, dass in einer Retrospektive auch die dringlichsten Themen besprochen und daraus Verbesserungen abgeleitet werden? Wir sind immer wieder überrascht, wie Teams sich in Bereichen weiter verbessern (wollen), in denen Sie unserer objektiven, weil aussenstehenden Meinung, nicht unbedingt den grössten Verbesserungsbedarf haben.
Klar, jede Verbesserung ist grundsätzlich positiv zu bewerten, doch auch hier gibt es ab einem gewissen Zeitpunkt einen stark abnehmenden Grenznutzen und den Hang zum so genannten Gold-Plating - dem Arbeiten an eine Aufgabe über die Anforderungen hinaus. Andere Bereiche werden ignoriert, und man fokussiert sich in seinem Verbesserungsprozess auf einige wenige Faktoren, wie z.B. die technische Exzellenz, anstatt sich mehr der Teamdynamik oder dem Produktfokus zu widmen.
Es ist kein Geheimnis, dass Extrovertierte in Unternehmen, so wie diese konstruiert sind, einen enormen Vorteil haben. Produktives, selbstbewusstes und zielstrebiges Auftreten wird fast immer honoriert. Doch das bedeutet mitnichten, dass introvertiertere Persönlichkeiten weniger mitzuteilen haben - Sie kommen nur nicht dazu. Genauso verhält es sich auch bei vielen Retrospektiven. In vielen Teams bilden sich nach einiger Zeit Meinungs- und Sprachführer heraus, und so wird die Retro im schlimmsten Fall von einigen wenigen Personen dominiert. Dies führt unter anderem auch dazu, dass nicht immer der richtige Fokus gelegt wird (siehe oben).
Ein versierter Scrum Master kann natürlich mit geschickt eingesetzten Techniken, zum Beispiel Brainwriting, anonymen Votes oder 1-2-4-alle (bei geschickter Gruppeneinteilung) diesen Effekt etwas reduzieren. Letztlich wird es jedoch oft dabei bleiben, dass viele Meinungen und Insights ungehört bleiben, was dem Verbesserungsprozess oftmals im Wege steht.
Kommen dir als Scrum Muster die oben beschriebenen Herausforderungen bekannt vor? Dann ist es vielleicht an der Zeit, etwas Neues auszuprobieren. Wir zeigen in den folgenden Abschnitten, wie der team.tschegg deine Retrospektiven verbessern, neue Erkenntnisse generieren und dein Team zu neuen Höhenflügen aktivieren kann!
Der team.tschegg ist rasch ausgefüllt. Circa 45 Minuten sind pro Person zu veranschlagen. Statt Retrotools.io oder einem Miro-Board kann alternativ der team.tschegg durch das gesamte Team genutzt werden. Die Retrospektive-Zeremonie kann dazu genutzt werden, den team.tschegg zu beantworten. So kann der Scrum Master auch sicherstellen, dass möglichst das gesamte Team teilnimmt. In der Regel lohnt es sich, auch eine "Aussenperspektive" zu erhalten. Dies kann erreicht werden, indem zum Beispiel die Stakeholder des Teams mit eingebunden werden. Dazu zählen zum Beispiel wichtige interne Anspruchsgruppen wie Linien- oder Fachverantwortliche, aber auch der Agile Coach oder Personen aus anderen Teams, die regelmässig mit dem Team arbeiten.
Die Beantwortung des team.tschegg ist absolut anonym und jede Beantwortung hat das gleiche Gewicht. Zudem hilft die Anonymität in der Regel, offen und ehrlich den Finger in die Wunde zu legen und somit aufzuzeigen, was wirklich verbesserungsbedürftig ist. Das Ergebnis ist demnach auch eine Reflektion der Meinung der gesamten Gruppe und nicht die einiger weniger Personen.
In der nächsten Retrospektive präsentiert der Scrum Master die Ergebnisse des team.tschegg. Entlang der fünf Teamdimensionen sind Abweichungen sofort identifiziert und augenscheinlich. Erkenntnisse müssen nicht mehr mühsam erarbeitet und analysiert werden, sondern offenbaren sich selbstverständlich und automatisch. Spätestens zu diesem Zeitpunkt wird deutlich, an welchen Themen mit höchster Priorität gearbeitet werden sollte und wo das Team schon einen soliden Stand hat und Massnahmen in unmittelbarer Zukunft vielleicht nicht zwingend nötig sind. Der Fokus wird damit auf die Dinge gelegt, die dem Team den grössten Mehrwert bringen.
Die Ergebnisse besitzen zudem eine hohe Validität, da sie nicht von einem, im schlimmsten Fall externen, Experten oder einer kleinen Gruppe von Personen erarbeitet wurden, sondern vom gesamten Team. Sollten einzelne Teammitglieder überhaupt nicht mit den Einschätzungen einverstanden sein, eröffnet sich hier direkt die Möglichkeit, tiefer in die Analyse einzutauchen, um die Ergebnisse besser zu verstehen.
Mithilfe des team.tschegg werden Verbesserungspotenziale also unmittelbar ersichtlich. Das Team kann dank der Facilitation des Scrum Masters nun konkrete Massnahmen ableiten und vereinbaren. Dabei hilft oftmals ein Causal-Loop Diagramm, um die Ursachen genauer zu verstehen und gezielt Massnahmen zu entwickeln. Die erarbeiteten Massnahmen werden dann wie gewohnt im nächsten Sprint Backlog priorisiert und umgesetzt. Dabei kann es durchaus sein, dass einige Massnahmen erst noch in kleinere Teilschritte heruntergebrochen werden müssen, da der team.tschegg die Stärke hat, auch fundamentale Probleme aufzudecken bzw. zu adressieren. Dementsprechend sollte der Scrum Master den Zeithorizont bis zur Umsetzung, respektive Wirkung, im Blick haben und das Team entsprechend sensibilisieren.
Gemäss unserer Erfahrung vernachlässigen Teams die Wirkungskontrolle vereinbarter Massnahmen leider allzu oft. Sobald eine Massnahme umgesetzt ist, wird sie vergessen. Ob die Massnahmen die gewünschte Wirkung erzielt haben (oder überhaupt eine Wirkung), ist meistens nicht bekannt. Der team.tschegg diszipliniert hier das Team, vereinbarte Massnahmen auf deren Wirkung zu kontrollieren. Um die Wirksamkeit von Massnahmen zu ermitteln, empfehlen wir dringend, den team.tschegg nach einem gewissen Zeitraum nochmals durchzuführen. Da der team.tschegg in aller Regel mehr als "Quick Wins" und oberflächliche Verbesserungen als Resultat hervorbringt, sollte der Zeitraum bis zur Kontrolle auch entsprechend gesetzt werden. Wir empfehlen drei bis sechs Monate - dies ist trotz unserer VUCA-Umwelt angemessen.
Ein kleines Beispiel: Nehmen wir an, der Scrum Master hat eine Teambildungsmassnahme durchgeführt, um das Team im Laufe der herausfordernden Corona-Zeit intakt zu halten. Falls die Teambildungsmassnahme die Teamdynamik nicht verbessert hat, war die Wirkung der Massnahme eventuell überschätzt oder der Effekt ist stark verzögert. In jedem Fall kann das Team nun in der gemeinsamen Analyse datenbasiert das weitere Vorgehen entscheiden und verliert sich nicht in Mutmassungen, Annahmen und Bauchgefühlen.
Der team.tschegg ist das Tool für Teams zur Identifikation von Potenzialen und zur kontinuierlichen Verbesserung über die fünf wichtigsten Dimensionen erfolgreicher Teams. Falls du als Scrum Master auch dein Team aktivieren und mehr über den team.tschegg erfahren möchtest, kannst du hier deine Unterlagen anfordern oder uns natürlich auch jederzeit direkt kontaktieren.
Keine Kommentare bis jetzt
Lass uns wissen, was du darüber denkst.