Lessons learned vs. Retrospektiven

Die meisten Menschen, die in Organisation arbeiten, haben die beiden Begriffe wahrscheinlich schon einmal gehört: Lessons learned und Retrospektiven.
Bei beiden Gruppenformaten geht es darum, Reflexion und Lernen zu organisieren und Verbesserung abzuleiten. Sie sind also irgendwie ähnlich. Manche denken sich nun: „ist doch dasselbe, nur ein anderer Name“.
Je nach Organisation und konkreter Durchführungspraxis mag das in der Tat so sein. Aber, es gibt Unterschiede, die sich aus der Historie erklären lassen und die Relevanz für die Praxis in Unternehmen haben (sollten).

In diesem Artikel möchte ich mich mit diesen Unterschieden beschäftigen und Erkenntnisse basierend auf meinen Erfahrungen in der Moderation von beiden Formaten bei Kunden ableiten.

Ich starte jeweils mit einer Kurzdefinition:
Eine Retrospektive ist ein regelmäßig stattfindendes, moderiertes Teamformat, in dem die Zusammenarbeit und der Arbeitsprozess reflektiert werden, um konkrete Verbesserungen für weitere Zusammenarbeit zu vereinbaren.

Lessons learned ist ein strukturiertes Reflexionsformat, in dem Erfahrungen und Erkenntnisse aus einem Projekt, Meilenstein oder Ereignis so festgehalten und aufbereitet werden, dass sie in zukünftigen Vorhaben wiederverwendet und organisationsweit weitergegeben werden können.

Lessons learned: Wissenstransfer in der Organisation

Lessons learned gibt es bereits deutlich länger als das Konzept der Retrospektiven. Es kommt aus Organisationen, die systematisch aus sich wiederholenden Arbeitsschritten und Projekten lernen mussten.
Aus meiner Erfahrung mit Kunden ist Lessons learned besonders in produzierenden Unternehmen bekannt und theoretisch verbreitet.
Eine Art der Organisation, bei der es in den „Projekten“ oft im wahrsten Sinne des Wortes um Leben und Tod geht, ist das Militär. Hier ist es besonders wichtig, Erkenntnisse aus Einsätzen in die Breite zu bringen, so dass der Rest der Organisation davon profitieren kann. Entsprechend institutionalisiert ist das Vorgehen dort auch. Die US Army hat 1985 das Center for Army Lessons Learned (CALL) eingerichtet, um Erkenntnisse zu sammeln, auszuwerten und zu verbreiten (Quelle).

Lessons learned zielt typischerweise darauf ab, Erfahrungen und Erkenntnisse aus einer Maßnahme so zu sichern, dass andere sie später wiederverwenden können. Es geht also vor allem um Wissensmanagement und Transfer.
In viele Organisationen passieren lessons learned meist punktuell, häufig am Ende eines Projekts oder nach einem Meilenstein. Damit bekommt das Format dann schnell den Charakter eines Abschlussrituals. Das beeinflusst dann auch den Output: Lessons learned enden nicht selten in einer Liste von Beobachtungen und Erkenntnissen.
Wie danach damit umgegangen wird, hängt sehr vom jeweiligen Kontext der Organisation ab: Wie im Falle der US Armee können daraus best practice Handbücher enstehen. Oder aber die Ergebnisse werden dann „irgendwo abgelegt“ und meist nicht mehr gefunden.

Retrospektiven: Prozess der Zusammenarbeit im Team

Retrospektiven kommen aus der agilen / adaptiven Produktentwicklung und haben als bewusst moderiertes Teamformat durch Norman Kerths Buch „Project Retrospectives“ (2001) besondere Verbreitung erfahren.
Das Format wurde dann sogar als Event in die Scrum-Methodik aufgenommen, mit dem expliziten Zweck, „Qualität und Effektivität“ zu steigern und konkrete Verbesserungen für den nächsten Sprint zu planen.
Es ist daher nicht verwunderlich, dass Retrospektiven besonders in IT-nahen Unternehmen verbreitet sind.
Zweck einer Retrospektive ist es, die Zusammenarbeit und den Arbeitsprozess des Teams zu verbessern im Hier und Jetzt, also während eines Projektes und nicht erst am Ende (wie bei lessons learned). Das macht im Kontext der adaptiven Produktentwicklung viel Sinn. Es ist viel Ungewissheit im Prozess, daher sollte man in regelmäßigen Abständen über Veränderungen reflektieren und Anpassungen vornehmen und zwar im Hier und Jetzt, nicht erst danach.

Retrospektiven sind regelmäßig wiederkehrend und je nach Frequenz bewusst kurz gehalten und dadurch stärker auf kleine, testbare Veränderungen ausgelegt. Das beeinflusst auch den Output: Während lessons learned nicht selten in einem Erkenntnisdokument enden, gibt es am Ende von Retrospektiven konkrete Vereinbarungen über nächste Schritte für das nächste Arbeitsintervall, inklusive Verantwortlichkeiten.

Abgrenzung zu einem Sprint Review oder Review Meeting

Im Scrum gibt es ein weiteres Format namens Review. Ähnlich wie bei lessons learned geht es hier um Inhalte (im Gegensatz zur Retrospektive).
Im Scrum bezieht sich ein Review auf das letzte Inkrement / den letzten Sprint. Ziel ist es Feedback zum Ergebnis zu bekommen, um dann ggf. Kurskorrekturen am Produkt und dem Backlog vorzunehmen. Ergebnis eines Reviews können und sollen damit Änderungen von Prioritäten im laufenden Projekt sein.
Auch Lessons learned sind rückblickend aber inhaltlich noch deutlich generalisierbarer. Es geht um für die Organisation relevante Erkenntnisse, ohne dass daraus sofort Änderungen oder konkrete Prioritätsentscheidungen folgen.
In der Praxis wird ein Sprint Review oft als Demonstration gelebt, also eher wie „Inhalte zeigen“, ohne daraus Anpassungen und Repriorisierungen abzuleiten. So entsteht die Verwechslung mit Lessons learned, weil „Lernen“ dann in anderen Formaten landet. Das ist kein semantischer Streit, sondern ein Symptom: Die Organisation nutzt das Review nicht als Entscheidungspunkt, sondern als Vorführen der Arbeit.

Auf die konkrete Praxis kommt es an!

Ich möchte keine Wortklauberei betreiben und mich an Begriffen aufhängen. Am Ende kommt es auf die konkrete Praxis in der Organisation an, wie ein Format dann konkret durchgeführt und benannt wird.
Aus meiner Erfahrung ist es jedoch sinnvoll vom Zweck her zu unterscheiden, ob es um Wissenstransfer in die Organisation geht (also die Konservierung von Wissen und Erkenntnissen), so dass in zukünftigen Projekten gewisse Dinge beachtet oder vermieden werden, oder der Fokus auf dem Prozess der Zusammenarbeit in einem Team liegt und es darum geht, jetzt konkrete Entscheidungen zu treffen, diese zu verbessern (wie bei einer Retrospektive).

Und es kommt darauf an, die Formate richtig durchzuführen. Denn, Lessons learned sterben am Ablageort, Reviews sterben am Demo-Modus und Retrospektiven sterben durch Schuldzuweisungen.

Hilfreich für beides: die Prime Directive

Ich bin ja ein großer Star Trek Fan, allerdings geht es hier um eine andere Prime Directive.
Norman Kerth schlägt seine Prime Directive als eine Art Präambel vor zum Start einer Retrospektive:

„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.“

Aus meiner Sicht ist dieser Hinweis genauso auf Lessons learned anwendbar.
Wenn der Inhalt wirklich ernst genommen wird, dann trägt die Prime Directive dazu bei (neben einer gekonnten Moderation), dass das Format nicht in eine Dynamik von Schuldzuweisung, Rechtfertigung und Politik verfällt.

Ursprünglich gedacht ist die Prime Directive für Retrospektiven. Ich betrachte sie jedoch auch für Lessons learned als sehr sinnvoll. Gerade weil Lessons learned in vielen Unternehmen als „Projektabschlussdokument“ in Richtung Rechtfertigung und politische Selbstabsicherung kippen, kann die Prime Directive als Schutz wirken.
Dabei gilt es jedoch vorher zu klären, wie genau das Ergebnis von Lessons learned später verwendet werden wird. Lessons learned werden öfter in Form von Dokumenten weitergegeben, in Audits zitiert oder in Governance-Runden verwertet. Wenn im Raum die Erwartung mitschwingt, dass Aussagen später personenbezogen rückgekoppelt werden, wird die Prime Directive schnell zur Floskel und kann Vertrauen beschädigen.

Keine Schuldzuweisung sollte nicht missverstanden werden als keine Verantwortung übernehmen (müssen). So kann man unterschieden zwischen menschlichem Fehler, riskantem Verhalten und bewusst rücksichtsloser Regelverletzung; für Letzteres sind Konsequenzen legitim, ohne dass man in Sündenbocklogik verfällt. (siehe dazu auch meine Buchbesprechung von „right kind of wrong“.

Retrospektive: Die konkrete Durchführung

In meinen Rollen beim Kunden moderiere ich in verschiedenen Kontexten Retrospektiven, oft im Rahmen von Management-Meetings.

Den konkrete Prozess, den ich verwende, habe ich vor einigen Jahren auf diesem Blog beschrieben. Am Ende des Artikels beschreibe ich auch, wie man von noch sehr allgemeinen Verbesserungspotenzialen zu konkreten Vereinbarungen kommt. Genau nach diesem Vorgehen arbeite ich auch mit den Management-Teams meiner Kunden.