Lessons Learned vs. Retrospektive: schneller lernen oder besser lernen?

Aufgrund der Vorbereitung des Führungssymposiums der Manufaktur für Führungskultur im Mittelstand habe ich mich in den letzten Tagen intensiver mit dem Begriff der Retrospektive beschäftigt.

Die Retrospektive ist eine sich häufig wiederholende Form der Reflektion, die wir vor allem aus dem agilen Umfeld kennen. Es gibt unterschiedlichste Arten eine Retrospektive durchzuführen, zum Beispiel 4L (Liked, Learned, Longed For and Lacked) oder die Starfish-Retrospektive. Das Ziel ist immer schnell eine Selbstreflexion durchzuführen, um für den nächsten Arbeitsabschnitt gewappnet zu sein. Sicherlich eine gute Idee, die auch über ein Softwareentwicklungsprojekt (wie in Scrum beschrieben) benutzt werden kann.

Ist damit aber das gute alte Lessons Learned Geschichte? Lessons Learned ist eine strukturierte Methode aus den 90er Jahren. Im Projektmanagement ist sie vor allem in der letzten Phase – der Abschlussphase – verankert. In der Linienarbeit kommt der Begriff häufig dann ins Spiel, wenn wir eine Situation nachträglich analysieren und bewerten. Allerdings sind die Lessons Learned mehr: es ist eine strukturierte Methode zur systematischen Sammlung, Bewertung, Anwendung und Weitergabe von Erfahrungen, die bei Projekten oder anderen Arbeitsprozessen gemacht wurden. Es sollen positive und negative Erfahrungen berücksichtigt werden.

Stehen somit beide Methoden im Gegensatz?

Ich glaube „Nein“, wenn wir den Ansatz nehmen,

dann verbinden wir beide sehr leicht.

Um z. B. klassischen Projektmitarbeiter den Übergang in Richtung Agilität zu vereinfachen, könnte man am Ende jeder Iteration eine Retrospektive und nach einem Release eine Lessons Learned als einmalige Veranstaltung durchführen. Mit diesen kleinen “Trick“ fangen Sie sowohl klassische als auch agile Projektmitarbeiter ein.

Ihr Standpunkt? Schreiben Sie mir, ich freue mich auf Ihre Anmerkungen und Fragen: michael.taube@deutsche-projekt-akademie.de