Retrospektiven – Lessons Learned

Die Erfahrung nimmt ein furchtbar hohes Schulgeld, aber sie lehrt wie sonst keiner.“ (Thomas Carlyle)

Eine Eigenschaft von Projekten ist, dass sie einmalig sind. Aber dennoch stossen viele Projektleiter auf gleiche oder ähnliche Probleme. Besser wäre es doch, positive und negative Erfahrungen aus Projekten festzuhalten und zu dokumentieren. Zwei Methoden, um solche Erfahrungen festhalten zu können, sind das Lessons Learned und die Retrospektive.

Ich werde Euch nachfolgend zeigen, warum wir aus Erfahrungen lernen können, warum wir als Team oder als Unternehmen aus Erfahrungen Einzelner lernen sollten und letztendlich erläutere ich Euch die beiden Methoden, deren Ablauf und einzelne Techniken.

Warum aus Erfahrungen lernen?

Vieles lernt man erst, wenn man es selbst erfährt. Ich weiss nicht mehr, wie oft ich meiner Tochter gesagt habe, die Herdplatte nicht anzufassen, weil sie heiss ist. Dennoch war es passiert: ich drehte mich kurz um und hörte den Schrei. Der Klassiker! Erst danach wusste sie, was ich meinte und hat die Herdplatte gemieden.

Auch aus dem beruflichen Leben kennt Ihr sicherlich solche Erlebnisse. Beispielsweise besuchte ich ein Seminar für Workshop-Methoden. Danach hatte ich nicht unbedingt das Gefühl einen Workshop moderieren zu können. Erst als ich eine Workshop-Moderation durchführen durfte, konnte ich anhand der Körpersprache und Reaktionen der Teilnehmer erkennen, wie gut die Methode angekommen ist. Aber auch am Ende sehen, ob wir das Ziel gemeinsam mit der Methode erreicht haben. Beim nächsten ähnlichen Setting konnte ich gleich darauf eingehen, bei einem neuen Ziel und neuen Setting musste ich wiederum neue Erfahrungen sammeln. Also: Ich nutze meine Eindrücke und verknüpfe diese mit der Workshop-Methode.

Wissenschaftliche Erkenntnisse zeigen, dass das Gedächtnis in erster Linie kein Speicher ist, in dem Wissen und Fakten eingelagert werden. Um sich an etwas zu erinnern, müssen Verknüpfungen zwischen Informationen hergestellt werden, wobei diese sich auch auf den verschiedenen Gehirnhälften befinden können.

Was bringt der Erfahrungsaustausch für mein Team bzw. für meine Unternehmung?

In einem Projekt sind viele Menschen beteiligt, die alle ihre eigenen Erfahrungen machen. Jeder wird dementsprechend seine Lehren gezogen haben und sich dementsprechend im nächsten Projekt verhalten. Wäre es aber nicht klüger, dass wir selbst nicht unbedingt die Erfahrung machen müssen, sondern von Anderen lernen könnten? Oder ist es nicht spannend zu sehen, wie andere die gleiche Situation einschätzen und welche Ideen Andere haben, mit einer Situation umzugehen, bzw. wieder aus solch einer Situation rauszukommen?

Erst wenn man gemeinsam Situationen reflektiert, kann ein Erfahrungsaustausch Stattfinden und Ideen generiert werden, um Probleme zu umschiffen, zu beheben oder um positive Erlebnisse wieder herzustellen.

Es gibt zwei Methoden, so dass im Projekt bzw. im Team Erfahrungen offen zu kommunizieren und diskutieren:

  • Lessons Learned
    Das Lessons Learned ist eine Methode des Wissensmanagements. Sie sollte mindestens am Ende eines Projekts durchgeführt werden, besser ist es, das Lessons Learned regelmässiger.
  • Retrospektive
    Die Retrospektive ist ein Bestandteil von Scrum, in der das Team aus dem vergangenen Sprint (Entwicklungszeitraum ca. 2-4 Wochen) Erfahrungen macht, um im nächsten Sprint besser zu werden.

Der gemeinsame Austausch von Erfahrungen führt es zu einer veränderten Fehlerkultur. Aber auch nur, wenn darauf bei der Moderation darauf geachtet wird, dass keine Schuldfrage geklärt wird, sondern alle Beiträge wertschätzend betrachtet werden.

Wie gehe ich vor?

Lessons Learned und Retrospektive nutzen Erfahrungen, um zu lernen und um besser zu werden. Dementsprechend können ähnliche Workshop-Techniken verwendet werden. Aber es gibt folgende Aspekte bei der Auswahl zu berücksichtigen:

  • Zeitliche Abstände: Die zeitlichen Abstände variieren. Während ein Lessons Learned am Ende eines Projekts empfohlen wird, wird die Retrospektive regelmässig nach einem bestimmten Zeitraum (ca. 2-4 Wochen) durchgeführt.
  • Ziel: Das Ziel des Lessons Learned ist zwar, dass das Team noch einmal Erfahrungen diskutiert, aber auch um diese für andere Teams festzuhalten. Bei der Retrospektive geht es darum, werden sie genutzt, um die Zusammenarbeit im Team zu verbessern.
  • Workshops: Die Workshops können ähnlich gestaltet werden, der zeitliche Rahmen muss aber bei einem Lessons Learned grösser sein, als bei einer Retrospektive.
  • Beteiligte: Bei der Retrospektive sollte das Entwicklungsteam beteiligt sein. Das Lessons Learned kann je nach Fragestellung auch einen grösseren Teilnehmerkreis (beispielsweise Management oder Kunde) umfassen.

Der Ablauf der Workshops ist bei beiden sehr ähnlich:

  1. Auf das Meeting einstimmen
    Im ersten Schritt werden die Beteiligten auf das Meeting eingestimmt. Um eine offene Atmosphäre zu erstellen, ist es wichtig, dass die Teilnehmer sich sicher fühlen. Es sollte daher darauf hingewiesen werden, dass nicht die Schuldfrage geklärt werden soll, sondern dass wirklich jeder Beitrag hilfreich und wertvoll ist. Damit der Workshop auch wertschätzend bleibt, sollten Rahmenbedingungen festgelegt bzw. wiederholt werden.
    Es bietet sich mindestens in der Storting-Phase und in der Norming-Phase an, als Einstimmung ein Stimmungsbild zu erhalten. Dazu gibt es verschiedene Techniken, die unten weiter beschrieben sind.
  2. Daten sammeln
    Es geht darum, herauszufinden, was gut und was nicht gut gelaufen ist. Hier können unterschiedliche Techniken verwendet werden (s.u.). Wichtig ist, dass wirklich nur Daten gesammelt werden, keine Bewertungen vorgenommen werden.
  3. Verbesserungsvorschläge erarbeiten
    Erfahrungsgemäss werden viele Themen angesprochen, so dass aus Zeitgründen wahrscheinlich die Themen erst einmal geclustert und priorisiert werden müssen. Für die priorisierten Themen können dann Verbesserungsvorschläge erarbeitet werden.
  4. Massnahmen ableiten
    Mit Hilfe der Verbesserungsvorschläge können Massnahmen abgeleitet werden. Die Lösungsvorschläge werden dazu bewertet und priorisiert. In der Retrospektive können Massnahmen dann im nächsten Sprint umgesetzt werden, beim Lessons Learned sollten diese Massnahmen dann für andere Projekte festgehalten werden.
  5. Meeting abschliessen
    Das Meeting sollte sinnvoll abgeschlossen werden. Dazu sollte das Ergebnis zusammengefasst werden und/oder das Gefühl der Teilnehmer noch einmal abgefragt werden. Der Moderator sollte sich ein Feedback einholen, um die Methode für das nächste Mal anzupassen bzw. eine andere Methode auswählen zu können.

Welche Techniken gibt es?

Es gibt eine Fülle von Techniken. Bei der Auswahl der Technik muss man gerade bei der Retrospektive die jeweilige Teamphase, in der sich das Team befindet, berücksichtigen, um das Team von einer Phase in die nächste Phase führen zu können. Beim Lessons Learned, wenn man es lediglich am Ende des Projekts durchführt, sind bereits alle Phasen hoffentlich durchlaufen worden.

Hier stelle ich einige der Techniken vor, gegliedert nach den beiden Schritten „Auf das Meeting einstimmen“ und „Daten sammeln“. Wenn du andere Techniken kennst, freue ich mich über einen Kommentar mit einer kurzen Beschreibung der Technik oder einem Link.

Auf das Meeting einstimmen

Stimmungsbild einholen/Ein-Wort-Methode/Wetterbericht

  • Ziel: Stimmung im Team prüfen
  • Ablauf: Um einfach die Stimmung zu prüfen, gibt es folgende Möglichkeiten
    • die Möglichkeit eine Skala auf einem Flipchart aufzumalen und die Teammitglieder können per Punkte ihre Stimmung anbringen. Beim Anbringen des Punkts sollte jeder mitteilen, warum er den Punkt dort gemacht hat.
    • Mittels eines Kreppbands auf dem Boden, können sich die Teammitglieder auch dementsprechend im Raum aufstellen.
    • Wetterbericht – Jeder Teilnehmer wird gebeten einen Wetterbericht zu malen, um seine Stimmung auszudrücken.
    • Ein-Wort-Methode – Jedes Teammitglied sagt mit einem Wort, wie es sich gerade fühlt.
  • Es sollten sich Techniken zum Ableiten von Massnahmen angeschlossen werden.
  • Teamphase: Storming und Norming-Phase

ESVP – Methode

  • Ziel: Ziel ist es hier die Teamstimmung herauszufinden.
  • Ablauf: Die Teammitglieder werden aufgefordert, darüber nachzudenken, mit welcher Haltung sie in das Meeting gekommen sind und dementsprechend den Anfangsbuchstaben der jeweiligen Haltung aufschreiben. Folgende Haltungen sind möglich:
    • Explorer: Ich bin hier, um neue Ideen und Einsichten zu entdecken
    • Shopper: Ich bin hier um vorhanden Informationen und Ideen anzuschauen
    • Visitor: Ich bin hier, weil ich einfach mal eine Pause von meiner täglichen Arbeit brauche, aber an das Meeting selbst habe ich kein Interesse.
    • Prisoner: Ich bin hier, weil ich gezwungen bin. Ich könnte etwas sinnvolleres mit meiner Zeit anfangen.
  • Die Zettel werden eingesammelt und anonym an die Pinnwand aufgehängt. Das Ergebnis wird diskutiert und wie es die Retro beeinflusse kann. Die Abschlussfrage ist dann, ob man diese Haltung auch im gesamten Projekt spürt. Gerade bei vielen Vistor und Prisoner-Zetteln sollte man solche Fragen stellen.
    Danach können die Faktoren, die zu dieser Haltung geführt haben, mit Hilfe anderer Techniken ermittelt werden und dementsprechende Massnahmen abgeleitet werden.
    Mehr unter: http://scrum-master.ch/agile/index.php/menu-main-retrospektive/menu-main-retrospektive-phasen/menu-main-retrospektive-phase-setthestage/menu-main-retrospektive-phase-setthestage-esvp
  • Teamphase: Storming- und Norming-Phase

Daten sammeln

Der Klassiker

  • Ziel: Massnahmen zur besseren Zusammenarbeit ableiten
  • Ablauf: Das Team soll auf Zetteln folgende Fragen beantworten: Was lief gut? Was kann verbessert werden? Daraufhin werden die Antworten diskutiert und geclustert. Zu jedem Cluster können Massnahmen erhoben werden.
  • Teamphase: In jeder Teamphase

Mad-Glad-Sad-Methode

  • Ziel: Massnahmen zur besseren Zusammenarbeit ableiten
  • Ablauf: Jedes Teammitglied schreibt auf, was ihn glücklich, was ihn frustriert hat und was ihn traurig gemacht hat. Die Karten werden nach dieser Logik geclustert. Die Themen werden detaillierter betrachtet und Massnahmen abgeleitet.
    Mehr Informationen unter: https://blog.mikepearce.net/2013/02/14/mad-glad-sad-retrospectives
  • Teamphase: In jeder Teamphase

Learning Matrix

  • Ziel: Massnahmen zur besseren Zusammenarbeit ableiten
  • Ablauf: Dabei wird eine Matrix aufgestellt, in der folgende Dinge von den Teilnehmern abgefragt werden: Was sollen wir beibehalten? – Was sollen wir ändern? – Neue Ideen? – Was oder wen haben wir geschätzt? Die Themen werden detaillierter betrachtet und Massnahmen abgeleitet. Weitere Informationen unter (https://www.innovationgames.com/learning-matrix/)
  • Teamphase: Für jeder Phase

Speedboat-Methode / Speedcar-Methode

  • Ziel: Massnahmen für eine bessere Zusammenarbeit ableiten
  • Ablauf: Ein Boot wird auf einem Flipchart gemalt. Man fügt Anker, Steine und eine Sonne sowie Wolken hinzu. Post-Ist oder Karten werden verteilt und die Teilnehmer müssen beantworten, welche Themen haben das Boot gestoppt, behindert, gefördert und was könnte helfen, das Boot schneller zu machen. Die Themen werden dementsprechend auf dem Bild hinzugefügt. Die Themen werden detaillierter betrachtet und Massnahmen abgeleitet.
    Mehr unter https://www.agilealliance.org/how-to-improve-the-speedboat-retrospective/
    Ähnlich dazu gibt es die Speedcar Methode. Dabei wird ein Auto gemalt mit einem Motor und Fallschirm als Bremse. (http://www.funretrospectives.com/speed-car/)
  • Teamphase: in jeder Teamphase

Starfish-Methode/KALM-Methode

Appreciation Technik

  • Ziel: Hier geht es eher darum, das Team zu wertschätzen
  • Ablauf: Jeder hat 10-15 Minuten Zeit über jedes Teammitglied positive Eigenschaften aufzuschreiben, die dann anschliessend in der Gruppe vorgestellt werden. Schöner wird die Methode, wenn dazu auch noch Pralinen mit den Worten (Ich möchte meine Praline an xx geben, weil…) verteilt werden. Derjenige, der genannt wurde, übernimmt die Pralinenschachtel und gibt sein Feedback und die Praline weiter (http://www.funretrospectives.com/token-of-appreciation/)
  • Teamphase: Norming und Performing-Phase (In der Storming-Phase passt es nicht unbedingt, da die Emotionen sehr hoch kochen können und der Sinn der Übung nicht gesehen wird. In der Forming-Phase hilft es auch noch nicht, da die Mitglieder sich noch nicht so gut kennen, aber kleine Aufmerksamkeiten sind sicherlich auch schon möglich.)

Rezept eines guten Scrum-Teams

  • Ziel: Rezept erstellen, was ein gutes Scrum Team ausmacht.
  • Ablauf: Es wird reflektiert, was das Team nun besser macht als in den älteren Sprints. Daraus wird ein Rezept gemeinsam geschrieben für ein gutes Scrum-Team und sichtbar abgelegt.
  • Teamphase: Eher in der Performing-Phase

Story Telling

  • Ziel: Massnahmen für eine gute Zusammenarbeit ableiten, zwischen den Zeilen hören
  • Ablauf: Jeder Teilnehmer soll eine Geschichte erzählen. Als Hilfe kann der Moderator einige Signal-Wörter (wie wütend, traurig, glücklich) vorgeben, die in der Geschichte mind. einmal genutzt werden müssen. Entweder erhalten die Teilnehmer Zeit, die Geschichte vorher zu schreiben und stellen diese dem Team vor (https://retromat.org/de/?id=93)
    Oder die Teilnehmer erzählen ihre Geschichte gleich. Vielleicht mit Hilfe von Legos: http://agilethings.nl/lego-goes-retro/
  • Teamphase: In einer sicheren und offenen Atmosphäre, wegen dem Lesen können zwischen den Zeilen gut einsetzbar in der Storming-Phase

Zusätzlicher Hinweis für das Lessons Learned

Lessons Learned werden nicht so regelmässig durchgeführt, wie die Retrospektiven; im schlimmsten Fall erst am Ende eines Projekts. Dann sind bereits alle Teamphasen durchlaufen, bestenfalls sind wir in der Performing-Phase gewesen. Da durch den längeren Zeitraum viele Erfahrungen gemacht worden sein könnten, die nicht alle in einem Workshop angesprochen werden können, sollte man den Fokus einschränken.

Beispielsweise könnten folgende Fragen gestellt werden:

  • Haben wir das Ziel des Projekts erreicht?
  • Warum konnten wir den Endtermin (nicht) halten?
  • Haben wir unsere Entscheidungen sinnvoll durchgeführt?
  • Wie war die Zusammenarbeit im Team?
  • Wie war die Kommunikation zwischen Team, Projektleitung und Management/Kunde?
  • War die Vorgehensweise sinnvoll?
  • Welche Probleme und Risiken waren vorher erkennbar? Was könnte man tun, um diese beim nächsten Mal zu verhindern?
  • Wenn Externe eingesetzt wurden: Welche Erfahrungen wurden mit ihnen gemacht?
  • Haben wir Teile der Entwicklung ausgelagert? Wie war die Erfahrung?

Ansonsten können Techniken aus der Retrospektive helfen, die Daten zu sammeln. Lediglich die Team-Stimmungsabfragen liefern am Ende wahrscheinlich keinen Mehrwert. Sobald man das Lessons Learned aber regelmässiger durchführt, kann man überlegen, ob nicht doch ein Stimmungsbarometer hilft, Probleme und Themen besser zu identifizieren.

Jedes Lessons Learned führt zu einer Liste von Erfahrungen, die, wenn sie für alle als wertvoll gehalten wird, auch festgehalten sein und zentral abgelegt sein müssen. Damit hat jeder in der Unternehmung die Chance aus den Erfahrungen der Anderen zu lernen. Beispielsweise beim Aufsetzen eines Projekts können wertvolle Hinweise bzgl. Kunden, Hintergründen usw. drinstehen. Diese helfen mir auf mögliche Probleme vorher einzugehen, so dass ich als Projektleiter nicht auch in diese Probleme renne und das Unternehmen möglicherweise den Kunden vollständig verliert.

Jetzt bin ich wieder bei meiner Tochter und der Herdplatte. Nur weil mir jemand sagt, dass die Herdplatte heiss ist, muss ich selbst die Erfahrung selbst noch einmal erleben. Hier gibt es die grosse Herausforderung, dass Erfahrungswissen so aufzubereiten, dass ein anderer dieses Wissen gerne aufnehmen möchte. Da hilft es nicht, wenn es eine Datenbank gibt und jeder kann dort ein paar Stichpunkte einfügen. Sinnvoller sind beispielsweise folgende Vorschläge:

  • Besser ist es die Lessons Learned an einer zentralen Stelle aufzubereiten. Vielleicht erkennt die zentrale Stelle, dass ein Fehler öfters gemacht wird und kann daraus Unternehmens-Massnahmen ableiten (beispielsweise Anpassung eines Geschäftsprozesses oder Einführung einer neuen Vorgehensweise).
    Oder sie kann als Coaches für andere Teams/Projekte fungieren und dort das Erfahrungswissen weitergeben.
  • Wie bereits erwähnt, Menschen lieben Geschichten, also warum nicht den Erfahrungsbericht auch als Geschichte aufbereiten.
  • Gut wäre auch, wenn man das Erfahrungswissen nicht nur schriftlich irgendwo festhält, sondern mündlich an Andere weitergeben kann.
  • Oder die Teammitglieder nach einem abgeschlossenen Projekt auf verschiedene Projekte verteilen. Damit können diese Teammitglieder ihr Wissen direkt in das neue Projekt einbringen.

Referenzen

2 Gedanken zu “Retrospektiven – Lessons Learned

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

w

Verbinde mit %s