Untergeordnete Seiten
  • Live-Session - Die Retrospektive - Kern agiler Prozesse
Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Diese Live-Session fand am 04. August 2011 um 11:15 Uhr wie immer auf unserer Live-Session-Portalseite statt.


In dieser Sendung besprechen Joachim Seibert und Martin Seibert Nutzen und Ablauf von Retrospektiven. Weitere Infos finden Sie auch in dieser Infothek hier: Retrospektive in der agilen Softwareentwicklung.


Aufzeichnung der Live-Session

Die Präsentation

https://www.slideshare.net/mseibert/agile-retrospectives-8768985


Die Retrospektive


Wann ist eigentlich die Gelegenheit, mal über die Effektivität der Zusammenarbeit mit dem Kollegen im Team zu sprechen oder Prozesse und Tätigkeiten in Frage zu stellen?
Wann haben Sie sich solche oder ähnliche Fragen das letzte Mal gestellt oder sich getraut, dies in Ihrem Team anzusprechen:


  • Wie gut arbeiten wir eigentlich zusammen?
  • Wie kommen wir im Team miteinander zurecht?
  • Können wir noch Dinge verbessern? Und wenn ja, welche?


Klassisches Projektmanagement hat darauf die Antwort: „Lessons learned“. Nach Abschluss des Projekts versucht man im Rückblick zu betrachten, wie das Projekt abgelaufen ist und was man vielleicht beim nächsten Mal verbessern könnte. Der große Nachteil daran ist: Für das gerade abgeschlossene Projekt ist es dann zu spät. Und ob das nächste Projekt mit dem gleichen Team stattfindet und ob alle anderen Rahmenbedingungen vergleichbar sind, bleibt offen.


Inspect & Adapt - kontinuierliche Verbesserung


Scrum dagegen setzt auf regelmässige Verbesserung schon während des Projektablaufs. Zum Ende jedes Sprints (fester Iterationszyklus von 1-4 Wochen) ist ein „Verbesserungsmeeting“ - die sogenannte Retrospektive – vorgesehen. Darin soll einem Scrum-Grundsatz genüge getragen werden: „Inspect & Adapt“. Wir betrachten regelmässig unsere Zusammenarbeit kritisch und überlegen, welche Anpassungen wir vornehmen können, um noch besser und effektiver zusammenarbeiten zu können.


Agenda der Session


  • Was ist eine Retrospektive?
    • kontinuierliche Verbesserung des Teams
    • Inspect & adapt
    • während des Projekts (!= lessons learned)
      • Fokus auf Verbesserung, Blick in die Zukunft (keine Kritik und Schuldzuweisungen)
    • Unterstützung der Teambildung (siehe Tuckmann, http://www.intarix.de/blog/die-teamuhr-von-tuckmann)
      • Retrospective wichtiger Bestandteil der "storming" und "norming" Phasen.
      • Bewußter, professioneller Umgang mit Teamstrukturen und -konflikten, Retrospektive bietet einen institutionalisierten Rahmen dafür
  • Retrospektive als Bestandteil des Scrum-Prozesses
    • ursprünglich nicht Bestandteil des Scrum-Frameworks
    • nach jedem Sprint!
    • aber: nicht nur Scrum!
  • Prototypischer Ablauf einer Retrospektive
    • Referenzwerk: "Agile Retrospectives" von Esther Derby et al.
    • die 5 Phasen der Retrospektive
      • Set the Stage: Alle Beteiligten auf das Meeting einstimmen und die Rahmenbedingungen erläutern
      • Gather data: Informationen / Meinungen / Stimmungen sammeln
      • Derive insights: Verbesserungspunkte finden und diskutieren
      • Determine actions: Todos definieren, die für eine Verbesserung sorgen sollen.
      • Close, Appreciations: Meeting beenden, Dank an Team, Feedback, wie das Meeting war.
  • Typischer Ablauf einer Retrospektive bei //SEIBERT/MEDIA
    • Set the stage: Aktivierungsfrage
      • kurze Einstimmung
      • Jeder!
      • Variieren (Wetterlage, Gericht, Autotyp, Tier)
    • Gather data: Histogramme
      • ca. 4-6 Fragen, Skala – bis ++
      • Sicherheitsabfrage, Team-Stimmung, Prozess
      • Fragen ggfs. anpassen
    • Derive insights: +/Delta
      • Fokus auf Stärken und Generierung von Verbesserungsvorschlägen
      • keine Kritik
      • einfach und schnell
      • direkte Erarbeitung von Verbesserungsvorschlägen
      • weitere Aktion: TimeLine
    • Determine Actions: Try, keep, drop
      • Gemeinsame Entscheidung (Konsent)
      • nicht entgültig
    • Close
      • Lobrunde
      • positive Stimmung
      • Retrospektive der Retrospektive (ROTI, +/Delta)
  • Praxistipps
    • neutralen Moderator (kein Team-Member)
    • genug Zeit nehmen (Team entscheidet)
    • Ablauf variieren
    • Auf negatives Feedback zur Retrospektive selbst eingehen
    • Entscheidung treffen im Konsent (http://soziokratie.blogspot.com/2009/08/konsent.html)
      • keine Gegenstimmen
      • Entscheidungen vorläufig, nicht unumstößlich ("lass es uns bis zur nächsten Retrospektive ausprobieren")
      • Thumbvoting


Weitere Informationen zur Retrospektive


Zentrale Prinzipien der Retrospektive


  • Nicht tote Berichte verfassen, sondern im Team direkt kommunizieren (reden statt schreiben)
  • Nicht Schuldfragen klären, sondern Lösungen finden
  • Nicht Probleme und Fehler unter den Teppich kehren, sondern aus ihnen lernen
  • Nicht einmalig, sondern kontinuierlich


Reflektion der Zusammenarbeit


Die Retrospektive unterscheidet sich sehr stark von den anderen Scrum-Meetings. Der produktive Teil des Sprint-Zyklus’ ist mit dem Sprint-Review abgeschlossen. In der Sprint-Retrospektive wird die Zusammenarbeit der Beteiligten nun offen und ehrlich reflektiert. Die Ursachen für Komplikationen werden gemeinsam durchdacht, damit nicht Symptome, sondern die Wurzeln der Probleme angegangen werden können.


Vergleichbar ist die Sprint-Retrospektive mit einer Einsatz-Nachbesprechung bei der Feuerwehr oder einem Debriefing beim Militär. Wie das Review-Meeting hat auch die Retrospektive vor allem einen Check-Charakter, hier ist der Fokus jedoch nicht auf das Produkt, sondern auf den Prozess und die Zusammenarbeit gerichtet. Die Erkenntnisse aus dem Sprint-Review und der Retrospektive gilt es dann zu nutzen, um Verbesserungsmaßnahmen einzuleiten.


Retrospektive und Teambildung


Die Durchführung von Retrospektiven ist ein wichtiges Hilfsmittel, um ein möglichst schnelles Durchlaufen des Teambildungsprozesses zu fördern. Regelmäßige Retrospektiv-Meetings mit dem Projektteam stärken das Verständnis unter- und füreinander und führen zur Herausbildung von Normen. Im Rahmen dieser Meetings spricht das Team offen und selbstkritisch über Herausforderungen im Projektverlauf, ohne allerdings einzelne Personen anzugreifen und für Probleme verantwortlich zu machen.