Lessons Learned

Was sind Lessons Learned, welche Beispiele und Phasen gibt es, und wann ist der ideale Zeitpunkt?

Gewonnene Erkenntnisse nutzen

„The only mistake in life is the lesson not learned“ soll Albert Einstein einmal gesagt haben. Frei übersetzt sind Fehler erlaubt, solange man aus ihnen lernt. Lessons Learned bezeichnet das Lernen aus Erfahrung, mit dem Ziel, die gewonnenen Erkenntnisse zukünftig aktiv zu nutzen. „Gewonnene Erkenntnisse“ ist die gebräuchlichste Übersetzung für den aus dem Englischen stammenden Begriff; „Lektion gelernt“ ist eine alternative und vielleicht sogar bessere Übersetzung.

Es gibt viele Beispiele, die zeigen, dass durch Handlungen Erfahrungen und idealerweise Erkenntnisse entstehen (können):

  • In Projekten kommt es zum Scope Creep; fortan werden Projektziele zum Projektstart definiert, dokumentiert und kommuniziert.
  • Beim Refactoring kommt zu es Mehraufwänden; zukünftig wird die Softwarearchitektur analysiert, bevor das Codieren beginnt.
  • Beim Requirements Engineering werden viele unnötige Anforderungen erhoben; bei jedem neuen Vorhaben wird zuerst der Systemkontext bestimmt.
  • Anwender sind mit einer Lösung unzufrieden; sie werden künftig frühzeitig und kontinuierlich in die Entwicklung einbezogen.
  • Workshops verlaufen chaotisch; sie werden fortan besser vorbereitet, zu zweit durchgeführt und moderiert und anschließend im Detail nachbereitet.

 

Phasen bei Lessons Learned

Die Beispiele zeigen, dass sich Lessons Learned häufig auf Organisationen – Unternehmen, Gremien, Teams etc. – beziehen. Oft wird der Begriff im Kontext von Projekten, im Zuge von Entwicklungen, oder beim Treffen von Entscheidungen verwendet. Doch auch Individuen lernen aus ihren Erfahrungen. Das Lernen aus Erfahrung geschieht sowohl für Individuen als auch für Organisationen in drei Phasen:

  1. Die Identifikation der Lektion, auch als Lessons Identified bezeichnet.
  2. Die Analyse der Lektion, auch als Lessons Analyzed bezeichnet.
  3. Das Lernen der Lektion und damit das eigentliche Lessons Learned.

 

Lessons Learned - Erkenntnisse gewinnen in drei Phasen

Bevor Individuen und Organisationen von ihren Erfahrungen profitieren können, müssen diese Erfahrungen als solche erkannt – also identifiziert – werden. Welche Probleme gab es bei einem Vorhaben? Was hat in einem Projekt gut oder weniger gut geklappt? Wo gibt es Verbesserungspotential? Sowohl aus positiven als auch aus negativen Erfahrungen können Individuen und Organisationen lernen.

Nach der Identifikation folgt die Analyse. Wieso hat etwas funktioniert oder nicht funktioniert? Welche Rahmenbedingungen gab es? Wie war das Setting im Projekt, die Kommunikation, die Motivation, das Tooling? Die Analyse der Erfahrungen ist wichtig, um als Organisation und/oder Individuum aus ihnen lernen und sie auf vergleichbare Situationen, Herausforderungen oder Projekte übertragen zu können.

Beim aktiven Lernen aus Situationen ist es wichtig, die Erkenntnisse zu dokumentieren, und sie so zu speichern, dass sie für alle Betroffenen zukünftig leicht zugänglich sind. Eine reine Ablage im Intranet wird bei einem kommenden Projekt leicht übersehen. Besser ist es bspw.

  • mit Checklisten zu arbeiten,
  • Dokumentenvorlagen zu optimieren und bereitzustellen,
  • Good Practices und Prozessschritte mit Softwaretools zu unterstützen,
  • und evtl. sogar konkrete Aktivitäten zur Auseinandersetzung mit bereits früher dokumentierten Lessons Learned im Projektplan zu berücksichtigen.

 

Der Zeitpunkt für Lessons Learned

Ein wesentliches Kriterium für Lessons Learned ist der Zeitpunkt, an dem sich die Beteiligten zusammensetzen, um wertvolle Erfahrungen zu identifizieren, sie zu analysieren und aus ihnen zu lernen. In diesem Kontext gibt es bspw.

  • das Projektreview als Nachbetrachtung eines Projekts oder einer Projektphase, und
  • die Retrospektive, die am Ende eines Sprints in Scrum durchgeführt wird.

Bei beiden Formaten geht es weniger um die erzielten Ergebnisse, sondern hauptsächlich um die Art und Weise der Zusammenarbeit, um Herausforderungen und Verbesserungsmöglichkeiten. Je nach verwendetem Format gilt es

  • Dinge, die gut gelungen sind,
  • Dinge, die weniger gut gelaufen sind,
  • Dinge, die man direkt stoppen sollte,
  • und Aspekte, die man ausprobieren könnte,

festzuhalten. Damit unterscheiden sich Retrospektiven und Projektreviews wesentlich von Code Reviews oder Sprint Reviews, bei denen es mehr um die Beurteilung der Arbeitsergebnisse als um die Zusammenarbeit geht.

Wichtig ist bei Lessons Learned – bspw. im Zuge eines Projektreviews oder in Form eines Workshops – die Vermeidung von Rückschaufehlern. Ein Vorgehen mag sich im Nachhinein als falsch erweisen, lernen können Individuen und Organisationen daraus aber nur, wenn die benötigten Informationen zum Zeitpunkt der damaligen Entscheidung bekannt waren. Je geringer die zeitliche Distanz zwischen Erfahrung und Erkenntnis, desto seltener kommt es zu einem Rückschaufehler. Darüber hinaus bieten frühzeitige Lessons Learned Sessions die Möglichkeit, die gewonnenen Erkenntnisse bereits im laufenden Projekt oder der laufenden Entwicklung zu nutzen.

Was macht t2informatik?

t2informatik - Wir entwickeln Software für großartige Unternehmen

Hinweise:

Hier finden Sie ein nützliches Hilfsmittel zur Dokumentation von Lessons Learned zum Download.

Und hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

Wissen kompakt: Wie funktioniert ein Code Review?

Wie funktioniert ein Code Review?

Wissen kompakt: Wie funktioniert ein Sprint Review?

Wie funktioniert ein Sprint Review?