> For the complete documentation index, see [llms.txt](https://prof.aheil.de/pmt/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://prof.aheil.de/pmt/tag-5.md). # Tag 5 ## Retrospektive Eine **Retrospektive** ist ein zentraler Bestandteil der agilen Entwicklung, insbesondere im Scrum-Framework. Sie bietet dem Team die Möglichkeit, über den letzten Sprint oder die letzte Iteration zu reflektieren und Verbesserungsmöglichkeiten zu identifizieren. Die Hauptziele einer Retrospektive sind: * Rückblick auf den Verlauf des vorherigen Sprints in Bezug auf die Mitarbeiter, das **Verhältnis zwischen den Teammitgliedern und dem Prozess**. * **Aufzeigen möglicher Verbesserungspunkte**. * **Erstellen eines Plans zur Umsetzung der Verbesserungspunkte**. Die Retrospektive ist ein wichtiger Mechanismus zur kontinuierlichen Verbesserung und fördert die Selbstorganisation und Anpassungsfähigkeit des Teams. Sie ermöglicht es dem Team, seine Arbeitsweise und Prozesse zu überdenken und anzupassen, um effektiver und effizienter zu werden. Es ist wichtig zu beachten, dass die Retrospektive ein sicherer Raum sein sollte, in dem jedes Teammitglied offen und ehrlich Feedback geben und erhalten kann. Bei der Retrospektive handelt es sich um einen **Team-Event**. Externe Mitglieder (z.B. Product Owner können auf Wunsch des Teams eingeladen werden). ## 4L Methode Die **4L-Methode** ist eine Technik für Retrospektiven in agilen Entwicklungsteams, insbesondere in Scrum. Die vier "L"s stehen für: * **Liked/Loved**: Was hat dem Team am Sprint wirklich Spaß gemacht? Insbesondere was funktionierte besser als erwartet? * **Learned**: Welche neuen Dinge hat das Team während des Sprints gelernt? Dies können technische oder organisatorische Aspekte sein. * **Longed For**: Welche Dinge wollte das Team während des Sprints haben, die nicht verfügbar waren? Auch dies können technische Aspekte wie beispielsweise zusätzliche Lizenzen einer bestimmten Software oder nicht-technische Punkte wie eine regelmäßigere Kommunikation mit dem Product Owner sein. * **Lacked**: Welche Dinge hätte das Team im Sprint besser machen können? Der englische Begriff “to lack” steht für “fehlen”. Also: was hat im Sprint gefehlt? Diese Methode ermöglicht es den Teams, ihre Erfahrungen und Erkenntnisse aus dem letzten Sprint zu reflektieren und Verbesserungsmöglichkeiten zu identifizieren. Nach der Sammlung entsprechender Punkte werden diese gruppiert, diskutiert, bewertet und entsprechend im nächsten Sprint umgesetzt. Die 4L-Methode ist insb. in unerfahrenen Teams einfach einzurichten und leicht zu verstehen. ### Benötigtes Material Die 4L-Methode kann sowohl in Präsenz als auch online durchgeführt werden. Folgendes Material ist für die beiden Varianten erforderlich: | Präsenz | Online | | --------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Meeting Raum | Video-Konferenzsystem mit Screensharing (BBB, WebEx, Microsoft Teams, Zoom etc.) | | 4 Whiteboards od. Flipcharts | Kamera/Mikrophon für jedes Team-Mitglied | | Marker | | | Post-Its/Sticky Notes (mind. ca. 10x15cm, besser ca. 15x20cm, Super Sticky) | | | Timer | Digitals Kollaborations-Tool (z.B Miro) | | | Timer | In Präsenz kann es sinnvoll sein, die Boards in den 4 Ecken des Raumen aufzustellen (s.u.). ### Vorbereitung Der Moderator, i.d.R. der Scrum Master setzt die Rahmenbedingungen um eine vertrauensvolle Atmosphäre zu schaffen. Zur Erinnerung: Es handelt sich um ein Team-Termin, der in einem sog. geschützten Raum (engl. Safe Space) stattfindet. Nichts was in der Retro besprochen wird, soll nach außen gelangen. Eine Möglichkeit diesen Rahmen zu setzen, ist es, den Team-Mitgliedern die Rahmenbedingungen der Retrospektiven nochmals in Erinnerung zu rufen. Mögliche Punkte, die der Moderator vorab dem Team erklären kann: * Das Meeting ist ein geschützter Raum. Nichts von dem Gesagten wird gegen irgendjemand verwendet. * Als Team nehmen wir uns die Zeit, um auf die vergangene Arbeit zu schauen, um herauszufinden, wie wir uns verbessern können. * Wir sind hier, um Dinge herauszufinden, nicht jemanden an den Pranger zu stellen. * Es ist wichtig zu verstehen, dass unter den gegebenen Umständen und mit den gegebenen Mitteln jeder im Team sein Bestes gegeben hat. ### Reflektion **Das Team erhält 10 Minuten** um über die vergangene Zeit (Sprint, Iteration etc.) zu reflektieren und Punkte zu notieren. Jeder Punkt sollte auf genau ein Post-It geschrieben werden. Dabei sollte unterschieden werden: **Liked/Loved**: Was hat wirklich Spass gemacht, was hat super funktioniert? Dies sind Dinge, Muster, Verhalten, Vorgehen, die im Team beibehalten werden oder sogar verstärkt werden sollten. **Learned**: Welche neuen Dinge hat das Team während des Sprints gelernt. Diese Punkte machen das Team besser. **Longed For**: Welche Dinge hätte das Team während des Sprints haben sollen, die nicht verfügbar waren? Was hat das Arbeiten unnötig schwer gemacht. Dies sind Dinge, die as Team in Zukunft besorgen oder beseitigen sollte. Bessere Keyboards, montags ein Obstkorb, fehlende Lizenzen etc. **Lacked**: Was hat definitiv gefehlt. Diese Punkte sind notwendig, dass das Team überhaupt arbeiten kann. Mehr Personal, Kaffee, funktionierende Rechner, Kommunikation mit dem Kunden. **Tipp**: Der Grat zwischen *Longed For* und *Lacked* ist nicht immer klar, bzw. in der Retrospektive nicht immer gleich ersichtlich. Der Hauptunterschied besteht darin, dass *Longed For* sich auf das Fehlen von etwas bezieht, das das Team gerne gehabt hätte, während *Lacked* sich auf Bereiche bezieht, in denen das Team glaubt, dass es besser hätte sein können. Nach Ablauf der Zeit, stellt jedes Team-Mitglied kurz seine Zettel for, und platziert Sie in dem jeweiligen Bereich auf dem entsprechenden Board. ### Action Items ermitteln Das Team splittet sich in 4 Teilgruppen. Jede Gruppe geht nun zu dem ihr zugewiesenen Board und soll versuchen alle Karten auf dem Board zu gruppieren (cluster). Ggf. können die Karten auch unter einer (neuen) Überschrift zusammengefasst werden. Das Team stellt sein Ergebnis kurz vor. Danach rotieren die Teams weiter zum nächsten Board. Dies wiederholt das Team so lange, bis die Anzahl der Zettel überschaubar wurde, oder kein Board mehr "optimiert" werden kann. **Pro Runde erhält das Team jeweils 10 Minuten Zeit.** Die nun übrig gebliebenen Zettel werden in "Action Items" umgewandelt. Für jeden Punkt wird eine verantwortliche Person bestimmt und ein Zieltermin festgelegt. * Welche Maßnahmen sind notwendig, dass die Punkte aus "Learned" im Team etabliert oder in Zukunft umgesetzt werden? Ggf. ist hier Wissenstransfer notwendig (Pairing, Schulung, ein kleiner Workshop o.ä. ). * Wie sind die Dinge erhältlich, nach denen sich das Team gesehnt hat ("Longed for"*).* Ggf. muss hier Budget beantragt werden, mit dem Management gesprochen werden etc.) * Was muss gemacht werden, um die fehlenden Punkte zu beheben. Alles im Bereich "Lacked" ist essentiell um das Team besser zu machen. Ggf. kann das Team dies nicht alleine, sobald es sich um organisatorische Punkte handelt, kann der Scrum Master oder weitere Personen unterstützen, die identifizierten Probleme zu behandeln. * Welche Maßnahmen werden umgesetzt um sicherzustellen, dass die Punkte aus Loved/Liked im Team beibehalten werden (z.B. einen Punkt in die DoD aufnehmen, der im Sprint praktiziert wurde) **Tipp**: Aus psychologischen Gründen ist es sinnvoll, die Boards "Learned" und "Loved/Liked" als letztes zu besprechen. Somit erhält die Retrospektive einen positiven Abschluss. ### Hintergrundwissen Da zunächst jeder im Team seine Punkte aufschreibt, ohne im Team darüber zu sprechen, kann jeder seine Ideen unabhängig voneinander entwickeln. Dies kann dazu beitragen, sog. Gruppendenken zu vermeiden und sicherzustellen, dass alle Stimmen (und Ideen) gehört werden. In der Psychologie wird dies auch als [Nominal-Gruppen-Technik](https://de.wikipedia.org/wiki/Nominal-Group-Technique) bezeichnet. ## Literatur * Esther Derby, Diana Larsen, David Horowitz, Agile Retrospectives Second Edition- A Practical Guide for Catalyzing Team Learning and Improvement, 2024, The Pragmatic Programmer, ISBN 9798888650370 * Marc Löffler, Retrospektiven in der Praxis - Veränderungsprozesse in IT-Unternehmen effektiv begleiten, 2014, dpunkt.verlag, ISBN 9783864901447 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://prof.aheil.de/pmt/tag-5.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.