Wie Scrum Teams Lessons Learned Workshops Durchführen

Immer wieder stellen sich Organisationen während agiler Transitionen die Frage, wie Sie in der "neuen Welt" Lessons Learned Workshops in einem Scrum-Team durchführen können. Sie befürchten, dass selbst-organisierte und selbst-gemanagte Teams ohne äußeren Antrieb nicht in der Lage sind Feedback-Schleifen zu Selbstkontrolle zu implementieren. Dieser Artikel erklärt die verschiedenen Feedbackschleifen von Scrum und wie sie die klassischen Lessons Learned Workshops in agilen Teams ersetzen.

Inhaltsverzeichnis

Lessons Learned in Klassischen Projekten

Es gibt viele Beschreibungen für das Konzept der Lessons Learned. Die von der National Aeronautics and Space Administration, der European Space Agency und der Japan Aerospace Exploration Agency verwendete klingt wie folgt: „Eine gelernte Lektion ist Wissen oder Verständnis, das durch Erfahrung gewonnen wurde. Die Erfahrung kann positiv sein, wie bei einem erfolgreichen Test oder einer erfolgreichen Mission, oder negativ, wie bei einem Missgeschick oder einem Fehlschlag… Eine Lektion muss signifikant sein, indem sie eine reale oder angenommene Auswirkung auf den Betrieb hat; gültig, indem sie sachlich und technisch korrekt ist; und anwendbar, indem sie ein spezifisches Design, einen Prozess oder eine Entscheidung identifiziert, die das Potenzial für Fehler und Missgeschicke reduziert oder eliminiert oder ein positives Ergebnis verstärkt.“

Das Project Management Institute (PMI) hingegen beschreibt Lessons Learned als „eine schriftliche Aufzeichnung und die systematische Sammlung, Bewertung und Verdichtung von Erfahrungen, Entwicklungen, Hinweisen, Fehlern und Risiken aus Projekten.“

Unabhängig von der gewählten Definition werden die Ergebnisse klassischer Lessons Learned Workshops jedoch nur selten praxisnah und strukturiert in Folgeprojekten angewendet. Ein Grund dafür mag die lange Zeitspanne zwischen dem Auftreten und der Auswertung der Ereignisse sein, da Lessons Learned Workshops immer erst am Ende eines Projekts stattfinden. Da Projekte per Definition einmalige, singuläre Unternehmungen sind, versuchen Lessons Learned Formate, Ereignisse eines abgeschlossenen, einmaligen Projektes auf Ereignisse eines anderen, zukünftigen, einmaligen Projektes zu projizieren. Klingt verrückt? Ist es auch! Werfen wir also einen Blick darauf, wie Erfahrungen und Lessons Learned in agilen Umgebungen noch während der Entwicklung eingebunden werden können, um dort Wirkung zu erzielen, wo es sinnvoll ist.

Der PDCA Zyklus

Der PDCA-Zyklus ist ein Management-Tool, mit dem Organisationen ihre Arbeit planen, ausführen und neu ausrichten können, indem sie die vier Schritte Plan – Do – Check – Act ausführen. Wikipedia gibt einen kurzen, aber umfassenden Überblick über einige der Kernmerkmale des PDCA-Zyklus.

PDCA wurde von W. Edwards Deming populär gemacht, der von vielen als der Vater der modernen Qualitätskontrolle angesehen wird; er bezeichnete es jedoch immer als „Shewhart-Zyklus“.

Das Konzept der PDCA basiert auf der wissenschaftlichen Methode, wie sie aus den Arbeiten von Francis Bacon (Novum Organum, 1620) entwickelt wurde. Die wissenschaftliche Methode kann als „Hypothese-Experiment-Evaluation“ oder als „Plan-Do-Check“ geschrieben werden. Walter A. Shewhart beschrieb die Fertigung unter „Kontrolle“ – unter statistischer Kontrolle – als einen dreistufigen Prozess von Spezifikation, Produktion und Kontrolle. Er bezog dies auch ausdrücklich auf die wissenschaftliche Methode von Hypothese, Experiment und Bewertung.

Deming betonte immer wieder die Iteration in Richtung eines verbesserten Systems, daher sollte PDCA immer wieder in Spiralen mit zunehmender Kenntnis des Systems durchgeführt werden, die zum Endziel konvergieren, wobei jeder Zyklus näher am Ziel als der vorherige ist. Mit anderen Worten: jeder Zyklus macht das bestehende System besser als es am Ende des letzten Zyklus war.

the four steps of the PDCA cycle
Abb. 1 - Die vier Schritte des PDCA Zyklus

Feedback Schleifen in Scrum

Schauen wir uns nun an, welche Feedback-Schleifen in Scrum existieren. Zwei Dinge können uns dabei helfen. Zum einen gibt uns ein Blick in den Scrum Guide eine Vorstellung davon, wo die beiden Säulen Inspektion und Anpassung ins Spiel kommen. Zum anderen gibt ein Blick auf das Logo, das im Scrum-Umfeld häufig verwendet wird, eine Vorstellung von den verschiedenen Schleifen in einer Scrum-Umgebung.

a graphical display of the scrum logo with three loops
Abb. 2 - Das weithin bekannte Scrum Logo

Das Scrum-Logo setzt sich aus drei Teilen zusammen. Wenn man das Scrum-Logo in seine Einzelteile zerlegt, erkennt man die Anzahl der Feedbackschleifen in Scrum, sowie die verschiedenen Ebenen der Produktentwicklung. Die unterste Ebene repräsentiert die kontinuierliche Produktentwicklung als eine fortlaufende, progressive, zukunftsorientierte Aktivität. Die erste und größte Feedbackschleife wird durch den einzelnen Sprint repräsentiert. Darüber hinaus gibt es eine kleinere Feedbackschleife, die den täglichen Planungs- und Entwicklungszyklus darstellt.

a graphical representation of the three Scrum feedback cycles
Abb. 3 - Die drei, im Logo versteckten, Feedback-Schleifen von Scrum

Die Entwicklung eines Produkts mit Scrum gliedert sich daher in drei Planungsebenen. Die Basis der Entwicklung ist eine kontinuierliche Produktentwicklung entlang der globalen Zeitachse. Diese wird durch die Sprint-Zyklen, die die erste Feedbackschleife in Scrum bilden, in Intervalle unterteilt. Innerhalb dieser Sprints gibt es täglich kleine Feedbackschleifen.

Lessons Learned in Scrum

Wie wir gesehen haben, gibt es in Scrum zwei Feedback-Schleifen. Ein Feedback-Zyklus umfasst die vier Schritte Plan, Do, Check und Act. Schauen wir uns an, wie der PDCA-Zyklus innerhalb der Scrum-Feedback-Schleifen umgesetzt wird und in welcher Form die vier Schritte des Feedback-Zyklus in die Praxis umgesetzt werden.

Beginnen wir mit dem PDCA-Zyklus auf der Sprint-Ebene. Es ist relativ leicht zu erraten, dass der Planungsschritt in der Sprint-Planung erfolgt. Die Ausführung des Sprints innerhalb von 1 - 4 Wochen ist die Phase, in der die Dinge getan werden, d.h. der "Do"-Schritt des Zyklus. Hier wird es dann spannend. In Scrum gibt es zwei "Check"-Ereignisse. Das eine ist das Sprint Review, das der Überprüfung des Produkts dient, und das andere ist die Sprint Retrospektive, die der Überprüfung der Organisation und des Teams dient. Beide Ereignisse dienen dazu, die im letzten Sprint erzielten Ergebnisse zu überprüfen. Aus beiden Events können/sollen sich Punkte zur Verbesserung bzw. zur Anpassung ergeben. Dies sind dann die Aktionspunkte, mit denen das Team handelt und den PDCA-Zyklus schließt.

the PDCA cycle and how Scrum events map to it
Abb. 4 - Der PDCA-Zyklus und eine Zuordnung der Scrum Events

Innerhalb des Sprints selbst gibt es, wie wir gesehen haben, den kleineren Feedback-Zyklus auf täglicher Basis. Im Daily Scrum bespricht das Team, welche Ziele des letzten Tages erreicht wurden, und, was noch interessanter ist, welche Ziele nicht erreicht wurden. In Bezug auf die nicht erreichten Ziele ergreift das Team dann Maßnahmen, um die identifizierten Probleme zu beheben. Außerdem bespricht und plant das Team die Aufgaben des nächsten Tages. Auf täglicher Basis dient das Daily Scrum also als Grundlage für die drei Schritte Check, Act und Plan. Die tägliche Arbeit selbst ist dann der Do-Schritt des PDCA-Zyklus.

Abschließende Gedanken

Innerhalb des Sprints selbst gibt es, wie wir gesehen haben, den kleineren Feedback-Zyklus auf täglicher Basis. Im Daily Scrum bespricht das Team, welche Ziele des letzten Tages erreicht wurden, und, was noch interessanter ist, welche Ziele nicht erreicht wurden. In Bezug auf die nicht erreichten Ziele ergreift das Team dann Maßnahmen, um die identifizierten Probleme zu beheben. Außerdem bespricht und plant das Team die Aufgaben des nächsten Tages. Auf täglicher Basis dient das Daily Scrum also als Grundlage für die drei Schritte Check, Act und Plan. Die tägliche Arbeit selbst ist dann der Do-Schritt des PDCA-Zyklus.

Zurück zum Blog

Von der Theorie in die Praxis? Besuchen Sie agile Trainings bei AgileSkills!

1 von 4
  • Lead Time und Cycle Time in Kanban Systemen

    Lead Time und Cycle Time in Kanban Systemen

    Bei der Diskussion von Kanban-Systemen tauchen oft die Begriffe "Lead Time" und "Cycle Time" auf. Allerdings verwenden verschiedene Leute diese Begriffe unterschiedlich, und manchmal werden sie sogar synonym verwendet. Dieser...

    Lead Time und Cycle Time in Kanban Systemen

    Bei der Diskussion von Kanban-Systemen tauchen oft die Begriffe "Lead Time" und "Cycle Time" auf. Allerdings verwenden verschiedene Leute diese Begriffe unterschiedlich, und manchmal werden sie sogar synonym verwendet. Dieser...

  • Throughput und Delivery Rate in Kanban Systemen

    Throughput und Delivery Rate in Kanban Systemen

    Obwohl die Begriffe Throughput (Durchsatz) und Delivery Rate (Lieferfrequenz) oft synonym verwendet werden, gibt es feine Unterschiede zwischen ihnen. Dieser Artikel erklärt den genauen Unterschied zwischen Throughput und Delivery Rate...

    Throughput und Delivery Rate in Kanban Systemen

    Obwohl die Begriffe Throughput (Durchsatz) und Delivery Rate (Lieferfrequenz) oft synonym verwendet werden, gibt es feine Unterschiede zwischen ihnen. Dieser Artikel erklärt den genauen Unterschied zwischen Throughput und Delivery Rate...

  • Ein kurzer Leitfaden über Objectives und Key Results

    Ein kurzer Leitfaden über Objectives und Key Re...

    Objectives and Key Results (OKRs) ist ein Zielsetzungsframework, welches Organisationen hilft, klare, messbare Ziele zu setzen. Dieser Artikel zeigt die Definition von OKRs sowie gute Beispiele, die Ihnen helfen könnten,...

    Ein kurzer Leitfaden über Objectives und Key Re...

    Objectives and Key Results (OKRs) ist ein Zielsetzungsframework, welches Organisationen hilft, klare, messbare Ziele zu setzen. Dieser Artikel zeigt die Definition von OKRs sowie gute Beispiele, die Ihnen helfen könnten,...

  • A Beginners Guide to Kanban Metrics

    Ein kurzer Leitfaden über Kanban Metriken

    Kanban-Boards werden von Teams verwendet, um ihren Workflow und aktuellen Aufgaben abzubilden. Leider fehlt vielen Teams das Wissen und die Fähigkeit, die Leistung ihres Workflows zu bewerten. Wie schnell werden...

    Ein kurzer Leitfaden über Kanban Metriken

    Kanban-Boards werden von Teams verwendet, um ihren Workflow und aktuellen Aufgaben abzubilden. Leider fehlt vielen Teams das Wissen und die Fähigkeit, die Leistung ihres Workflows zu bewerten. Wie schnell werden...

1 von 4
Dr.-Ing. Stefan Döbrich

Fragen und Antworten

Sie haben offene Fragen zu Agilität?

Sie haben noch offene Fragen zum Artikel, zu agilen Methoden, oder Probleme bei der Umsetzung von Agilität in der Praxis?

Schreiben Sie mir, und wir vereinbaren ein Erstgespräch! Wir machen uns gemeinsam auf den Weg. Versprochen!

Jetzt Kontakt Aufnehmen