Retrospektive Meetings durchführen – Kontinuierliches Verbessern

Retrospektive Meetings durchführen – Kontinuierliches Verbessern

Fehler kommen vor und sind OK, solange man aus diesen etwas lernt.
Retrospektive Meetings bieten die Gelegenheit dazu, aus der Vergangenheit für die Zukunft zu lernen. Durch Identifikation der Verbesserungsmöglichkeiten am gemeinsamen Arbeitsprozess können Erfolge noch effektiver und effizienter erzielt werden. Dadurch wird Produktivität des Teams verbessert.

Durch einen Erfahrungsaustausch lässt sich viel voneinander lernen. Tauschen Sie sich deshalb jetzt mit Experten auf Ihrem Gebiet aus und erweitern Sie Ihr Netzwerk! Treten Sie jetzt der exklusiven Gruppe für Projektmanager und Führungskräfte bei.

So führst du Retrospektiven im SCRUM durch

Dabei gibt es einen klaren Ablauf, der das Lernen erleichtert und so eine gelungene Retrospektive garantiert:

Ablauf des Meetings

Schritte der Retrospektive

Sicherheit schaffen

Für eine gute Retrospektive benötigen Sie einen geschützten Raum in dem sie durchgeführt wird. Alle Beteiligten müssen sich sicher sein, dass ihnen während und nach einer Retrospektive nichts passieren kann. So dürfen die Punkte aus der Retrospektive nicht im nächsten Jahresendgespräch gegen die Teammitglieder verwendet werden.

Sie benötigen eine Atmosphäre, die es den Teilnehmern ermöglicht, sich auf die Lernerfahrung einzulassen. Wählen Sie daher einen Raum, in dem Sie ungestört sind. Eingeladen werden nur an den Aktionen beteiligte. Als Nächstes präsentieren Sie das oberste Retrospektiven Prinzip:

Prime Directive
„Regardless of what we discover,
we understand and truly believe,
that everyone did the best job they could,
given what they knew at the time, their skills and abilities,
the resources available, and the situation at hand.“

Auf Deutsch:

Oberste Regel

Egal, was wir entdecken werden, wir verstehen und glauben ehrlich,
dass jeder unter der Voraussetzung seines derzeitigen Wissensstandes,
seiner derzeitigen Fähigkeiten und Kenntnisse,
mit den vorhandenen Ressourcen in der gegebenen Situation
sein Bestmögliches gegeben hat.

Die Geschichte dahinter ist sehr bewegend. Als eine Segelregatta in einen Sturm geriet war ein Segler über Bord gegangen und ertrunken. Alle waren tief getroffen. Der Skipper brachte alle zusammen und führte mit ihnen ein Gespräch. Er machte klar, dass sie nun darüber sprechen müsste, was zu dem Unfall geführt hatte. Er wollte aber vorausschicken, dass es keinen Schuldigen gibt. Er machte sehr deutlich, dass während des Unwetters jeder sein Bestes getan hatte und es aus diesem Grund nur darum gehen könne herauszufinden, was faktisch passiert sei und was daraus zu lernen sei.

Besprechen Sie dieses grundlegende Prinzip mit Ihrem Team. Erklären Sie auch, woher dieser Grundsatz stammt und wieso er so wichtig ist. Machen Sie deutlich, dass Sie tatsächlich alles in Ihrer Macht Stehende versuchen, damit jeder Teilnehmer frei und offen reden kann.

Dazu können Sie die folgende Übung durchführen. Teilen Sie an jeden Teilnehmer einen Zettel für eine geheime Umfrage aus. Fragen Sie anschließend die Gruppe, ob jeder offen und frei über seine Erlebnisse aus dem letzten Sprint berichten möchte. Bitten Sie alle Teilnehmer, mit JA oder NEIN zu antworten. Sammeln Sie nun die Zettel ein und prüfen, ob es einen Teilnehmer gibt, der mit NEIN gestimmt hat.

Sollten Sie einen Zettel mit NEIN finden, versuchen Sie zunächst für mehr Sicherheit zu sorgen. Bitten Sie die Gruppe, in den nächsten zehn Minuten einen entsprechenden Vorschlag zu erarbeiten, um einen höheren Sicherheitslevel zu erreichen. Setzen Sie diesen um und befragen wiederholt alle Teilnehmer. Falls Sie wieder ein NEIN erhalten, würdigen Sie diesen Umstand, aber führen die Retrospektive weiter durch.

Wir wissen nun, dass mindestens ein Teilnehmer noch nicht bereit ist offen zu reden. Das ist in Ordnung, darf uns aber nicht aufhalten. Jeder weiß jetzt, dass mindestens ein Teilnehmer kein ausreichendes Vertrauen in den Prozess, die Gruppe oder den Moderator hat. Es bleibt uns nichts übrig, als diese Tatsache zu akzeptieren. Das Vertrauen und die Bereitschaft, sich offen zu äußern, wachsen jedoch mit jeder Retrospektive. Da die Teilnehmer die Erfahrung machen, dass die Retrospektive ein Gewinn für ihre Arbeit ist, entsteht Vertrauen in den Prozess.

Fakten sammeln

Nachdem die Retrospektive durch das Schaffen von Sicherheit vorbereitet wurde, folgt das Sammeln von Fakten in Form kleiner Geschichten. Dabei schreiben die Teilnehmer die aus ihrer Sicht signifikanten Ereignisse aus dem letzten Sprint auf und heften diese Notizen an eine vorbereitete Pinnwand, auf der ein Zeitstrahl dargestellt ist. (Start of sprint → 1st week → 2nd week → today) Jeder Teilnehmer erzählt in ein oder zwei Sätzen, wieso dieses Ereignis für ihn oder sie wichtig war.
Reflektion und Nachbesprechung
Durchführung

  1. Der Moderator teilt Haftnotizen und Flipchart-Marker an Teilnehmer aus.
  2. In maximal fünf Minuten schreibt die Gruppe signifikante Ereignisse auf.
  3. Dabei arbeitet jeder für sich. Jeder schreibt pro Ereignis eine Haftnotiz.
  4. Nach Ablauf der Zeit gehen die Teilnehmer im Uhrzeigersinn an die Pinnwand und heften ihr Ereignis an die passende Stelle des Zeitstrahls.
  5. Zu jedem Ereignis wird eine kurze Geschichte erzählt (ca. zwei Sätze).
  6. Der Moderator fragt die übrigen Teilnehmer, was ihnen zu den Ereignissen einfällt, ob diese noch einen Kommentar haben.
  7. Die Teilnehmer beantworten die Frage, diese „Zusammenfassung“ dient der Integration der Geschichten.

Dabei sind zwei Dinge entscheidend. Es werden wertneutral „subjektive Fakten“ gesammelt. In diesem Teil entsteht der „Ton“ der Retrospektive. Es wird klar, ob es ein motivierendes Treffen oder eher eines, in dem die Teilnehmer „Dampf ablassen“ müssen, wird. Daraus kann der Moderator ableiten, wie er mit der Gruppe weiterarbeiten muss.

Nachdem die Timeline erstellt wurde sollte der Moderator das Team darauf hinweisen, wie viel sie bereits erreicht haben. Als die Freude darüber, was alles geleistet wurde, Oberhand gewinnt, entsteht eine von Erfolg geprägte Atmosphäre. Dabei erfährt das Team, wie es jedem Einzelnen ergangen ist. Dadurch wird ein gemeinsames Bewusstsein der vergangenen Erfahrungen erzeugt. Aspekte, die das Team zuvor nicht wissen konnte, treten in das Bewusstsein der Gruppe und können reflektiert werden.

Holen Sie sich meine Checklisten, Tipps und Tricks um Ihr Projekt auf Kurs zu bringen! Lernen Sie wie man Projekte richtig plant, durchführt und kontrolliert!

Funktionierende Prozesse finden

Nachdem das Team ein deutliches Bild vom letzten Sprint gewonnen hat, ist es an der Zeit, die Frage zu stellen, was sich bewährt hat und gut gelaufen ist. So werden die guten Dinge identifiziert und als Teil des Arbeitsprozesses des Teams sichtbar gemacht.

Durchführung

  1. Ein Flipchart oder eine Pinnwand mit der Überschrift „Was lief gut?“.
  2. Der Moderator teilt Haftnotizen und Flipchart-Marker an Teilnehmer aus.
  3. In maximal fünf Minuten schreibt die Gruppe alles auf, was aus ihrer Sicht gut lief.
  4. Jeder arbeitet für sich und verfasst jeweils eine Notiz für alles, was gut gelaufen ist.
  5. Nach Ablauf der Zeit heften die Teilnehmer im Uhrzeigersinn ihre Notizen an die Pinnwand.
  6. Zu jeder Notiz wird eine kurze Geschichte in ein oder zwei Sätzen erzählt.
  7. Abschließend fragt der Moderator die Gruppe, ob es Ergänzungen gibt oder ob jemand noch einen Kommentar hat.

An der Pinnwand hängen nun viele Beobachtungen dazu, was im Team gut lief. Sollte es darunter etwas geben, das alle Teammitglieder als besonders hervorhebenswert betrachten, kann diese Sache vom Team zu einer Verfahrensvorschrift erklärt werden. Allerdings behalten die Teammitglieder alles, was für sie gut funktioniert, auch ohne explizite Verfahrensvorschrift in Zukunft bei. Sie können die Ergebnisse dieses Schrittes auch im Teamraum aufhängen. So gewöhnen sich Teammitglieder im Laufe der Zeit an diese sichtbaren Prozessanweisungen.

Durch die Retrospektive werden funktionierende Prozesse also nicht nur transparent, sondern auch mit der Zeit institutionalisiert. Somit werden Prozesse nicht immer wieder ad hoc neu erschaffen, sondern zu selbstverständlichen Arbeitsweisen. Gleichzeitig erfolgt eine ständige Reflektion durch die wiederkehrenden Retrospektiven.

Separator

Dieser Zwischenschritt trennt die Retrospektive in zwei Teile – die Beschäftigung mit dem, was gut gelaufen ist, und mit dem was zu verbessern ist. Ohne diese Trennung laufen Sie Gefahr, dass die positive Energie aus dem ersten Teil nicht konserviert, sondern durch die Beschäftigung mit den „negativen“ Aspekten neutralisiert wird. Als Beispiel für einen Separator kann eine Danke Runde dienen. Nachdem die Teammitglieder zusammengetragen haben was sie in diesem Sprint gut gemacht haben, haben sie am Ende die Gelegenheit sich bei einem Kollegen oder generell für etwas zu bedanken. Es kann auch ein Film gezeigt werden, der Heiterkeit erzeugt. Filme funktionieren jedoch nicht in jedem Team.

Nichtfunktionierende Prozesse finden

Nach dem Separator geht es im vierten Schritt um die folgende Frage.

Was können wir an der Art und Weise, wie wir arbeiten, verbessern?

Dabei muss klar sein, dass wir nicht nach Fehlern suchen, sondern nach Verbesserungsmöglichkeiten.

Durchführung

  1. Ein Flipchart oder eine Pinnwand mit der Überschrift: „Was könnte verbessert werden?“
  2. Der Moderator teilt Haftnotizen und Flipchart-Marker an Teilnehmer aus.
  3. In maximal fünf Minuten beantwortet die Gruppe die Frage: „Was ließe sich verbessern?“
  4. Jeder arbeitet für sich und verfasst jeweils eine Notiz pro Verbesserungsvorschlag.
  5. Nach Ablauf der Zeit heften die Teilnehmer im Uhrzeigersinn ihre Notizen an die Pinnwand.
  6. Zu jeder Notiz wird eine kurze Geschichte in ein oder zwei Sätzen erzählt.
  7. Abschließend fragt der Moderator die Gruppe, ob es Ergänzungen gibt oder ob jemand noch einen Kommentar hat.

Dabei können folgende Fragen helfen um nicht funktionale Prozesse zu identifizieren:

  • Wie genau waren die Anforderungen spezifiziert? Eine andere Variante derselben Frage: Ist es vorgekommen, dass die Anforderungen mehrmals überarbeitet werden mussten und das Design dadurch verschoben wurde?
  • Gab es Zeit für einen Entwurf oder wurde sofort mit der Umsetzung begonnen?
  • War es schwierig, die bestehende Architektur mit neuer Funktionalität zu erweitern?
  • Hat der Kunde / Product Owner zum Erfolg der Umsetzung beigetragen? Wie organisiert, wie kompetent ist er? Wie kann man seine Bereitschaft zur Mitarbeit im Projekt bewerten?
  • Wenn Sie die Möglichkeit hätten, das gleiche Problem wieder zu lösen (z.B. denselben Code wieder zu schreiben), würden Sie etwas anders machen?
  • Hatten Sie alle Instrumente zur Hand, die zur Lösung der Fragestellung notwendig waren?

Nach dieser Übung sollten einige Zettel an der Pinnwand oder am Flipchart hängen. Jeder zeigt ein Hindernis (Impediment) auf.

Mögliche Hindernisse können sein:

  • Wir müssen häufiger testen.
  • Tester fehlen.
  • Wir besitzen nicht die benötigten Informationen.
  • Product Owner ist nicht verfügbar.
  • Es fehlt eine Klimaanlage.
  • Es ist zu laut.

Das Beseitigen dieser würde die Arbeit des Teams beschleunigen.

Dabei ist es wichtig, dass die Teammitglieder selbst die einzelnen Hindernisse identifizieren. Als die Betroffenen denken sie selbst über Hindernisse als Quelle der Verbesserungsmöglichkeiten nach. Der Moderator kann seine Verbesserungsvorschläge einbringen, sollte es jedoch erst nach dem Team tun und die Vorschläge genau wie alle anderen an das Flipchart hängen. Dadurch werden diese Vorschläge ent-personalisiert.

Im nächsten Schritt wollen wir herausfinden, wer die Macht hat, die identifizierten Hindernisse zu beseitigen.

Veränderungen einleiten

Zunächst wollen wir herausfinden worüber das Team selbst Kontrolle hat. Die identifizierten Hindernisse oder Verbesserungspunkte werden in zwei Kategorien gruppiert:

  • Dinge, die etwas betreffen, was das Team selbst verändern und verbessern kann
  • Dinge, die außerhalb des Teams stehen und die von der Organisation, vom Management oder von einem Kunden verändert werden müssen

Dazu wird ein Flipchart in zwei Spalten geteilt: Team und Organisation. Anschließend verteilt das Team alle Verbesserungsmöglichkeiten auf die entsprechenden Spalten. In der Spalte „Team“ könnten Dinge wie bessere Absprache mit dem Kunden, Coding Standards und Dokumentation stehen. In der Spalte „Organisation“: Product Owner fehlt, Product Backlog ist nicht priorisiert, mangelnde Hardware.

Jetzt haben wir die Information darüber, was das Team und was die Organisation verändern sollte, um eine höhere Produktivität zu erreichen.

Priorisierung

Die Liste der Hindernisse ist oft lang, es gibt sehr viel zu tun. Daher muss in diesem Schritt entschieden werden, wann wir an welchen Verbesserungen arbeiten sollten.

Das Team entscheidet, welches Hindernis sofort gelöst werden sollte und welche Veränderungen dem Team den meisten Produktivitätsgewinn bringen. Dabei priorisieren die Teammitglieder sowohl die Spalte, die das Team selbst im Griff hat, als auch die Spalte, die von der Organisation angegangen werden muss. So gewinnen wir einen klaren Überblick darüber, was das Team angehen möchte und was es vom ScrumMaster (im klassischen Projektmanagement Projektleiter) erwartet. Das Team schätzt nun, wie aufwendig das Bearbeiten der Hindernisse ist, die das Team lösen kann.

Am Ende der Retrospektive liegen also zwei Listen als Ergebnis vor:

  • Liste der Hindernisse, die das Team lösen kann (inkl. Schätzung)
  • Liste der Hindernisse, die der ScrumMaster (Projektleiter) lösen muss

Die dort aufgeführten Probleme müssen nun angegangen werden.

In Scrum wird im Sprint Planning 1 Meeting über das Ausmaß an Arbeiten in einem Sprint diskutiert. Daher wird auch besprochen, welches Hindernis das Team behandeln sollte. Hierfür sicher der ScrumMaster am Ende der Retrospektive die Liste der Hindernisse und bringt das so entstandene Impediment Backlog in das nächste Sprint Planning 1 mit. Die Teammitglieder verhandeln nun mit dem Product Owner, welche Items aus dem Impediment Backlog bearbeitet werden sollen. Es ist eine Sache des Product Owners, ob er diese Aufwände akzeptiert, denn es bedeutet, dass er weniger Funktionalität bekommen kann, als er zunächst annahm.

Im klassischen Projektmanagement kann dies in einem separaten Meeting oder im wöchentlichen Jour-fixe erfolgen.

Es ist zu empfehlen, die Retros nach jedem Sprint anders durchzuführen. Anregungen bietet der Retromat oder auch Starfish Retrospective.

Warum scheitern so viele Projekte?

  • In meinem Newsletter lernen Sie, wie Sie Projekte erfolgreich abschließen.
  • Zahlreiche Checklisten, Tipps und Tricks bringen Ihr Projekt auf Kurs.
  • Vorlagen für Business Case, Projektleitdokumentation und Fachkonzept.
  • Lernen Sie wie man Projekte richtig plant, durchführt und kontrolliert.
  • Bei der Anmeldung zu meinem Newsletter erhalten Sie das Buch „Projektmanagement in a Nutshell“ als Willkommensgeschenk.
Projektmanagement Tipps

Jetzt anfordern!

* Pflichtfeld
 
Kein SPAM. Ich hasse Spam genau so wie du.

Quellen und weiterführende Literatur:
Boris Gloger – Scrum: Produkte zuverlässig und schnell entwickeln
Starfish Retrospective
Retromat – Inspiration and plans for agile retrospective
Tasty Cupcakes – Agile Spiele

Falls Ihnen dieser Beitrag weitergeholfen hat, wäre es eine sehr nette Anerkennung meiner Arbeit wenn Sie z.B. Ihre Bücher über Amazon bestellen würden. Wenn Sie ein Produkt kaufen, erhalte ich dafür eine Provision. Für Sie ändert sich am Preis des Produktes gar nichts. Ich möchte mich an dieser Stelle jetzt schon für Ihre Unterstützung bedanken.
Bildquelle: Pixabay, lizensiert unter CC0

0 Kommentare

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.