Wichtige Ereignisse

Was ist passiert, und ungefähr wann? Ein Ereignis pro Idee.

Anfang Feb.: Projekt-Kickoff. Wir hatten ein klares Ziel, aber keine abgestimmte Definition of Done.
Woche 3 - Sarah kam vom Plattform-Team dazu und hat die API-Arbeit übernommen.
Mitte April: Der Kunde wollte das Reporting-Modul in Phase eins vorziehen.
Höhepunkte

Wann war das Team in Bestform, und warum?

So um Woche 8, als die erste Demo beim Kunden richtig gut ankam. Da hatte ich endlich das Gefühl, dass wir wissen, was wir bauen.
Der zweitägige Hackathon im April. Alle in einem Raum, keine Meetings, und wir haben das Suchproblem gelöst.
Ehrlich gesagt war für mich der Juli die beste Phase, als der Scope feststand und wir einfach loslegen konnten.
Tiefpunkte

Wann hatte das Team zu kämpfen, und warum?

Mitte April, als das Reporting-Modul vorgezogen wurde. Wir hatten gerade die nächsten sechs Wochen geplant, und alles war für die Tonne.
Die fehlgeschlagene Migration im Mai. Drei lange Nächte und viel gegenseitiges Fingerzeigen im Channel.
Der Juni war zäh. Ohne Designer haben wir bei der UI geraten und Arbeit doppelt gemacht.
Lehren für das nächste Mal

Was würden wir beim nächsten Projekt wiederholen oder ändern?

Den Hackathon vor Ort mindestens einmal pro Projekt wiederholen. Er hat beim Thema Suche den Knoten gelöst.
Beim Kickoff mit dem Kunden einen Prozess für Scope-Änderungen vereinbaren, inklusive wer freigibt und wie wir neu planen.
Jede Datenmigration vor der Release-Woche einmal komplett in einer produktionsnahen Umgebung durchspielen.

Was ist eine Timeline-Retrospektive?

In einer Timeline-Retrospektive rekonstruiert das Team die Geschichte eines längeren Arbeitsabschnitts, etwa eines Projekts, eines Quartals oder eines Jahres, indem es die prägenden Ereignisse in zeitlicher Reihenfolge festhält. Die Methode stammt aus der Community rund um agile Retrospektiven. Esther Derby und Diana Larsen beschreiben sie in ihrem Buch Agile Retrospectives: Making Good Teams Great als Übung zum Sammeln von Daten, und sie baut auf Norm Kerths früheren Arbeiten zu Projektretrospektiven auf. Jede Person trägt die Ereignisse ein, an die sie sich erinnert, versieht jedes mit einem ungefähren Datum und beschreibt, wie es sich damals angefühlt hat. Der eigentliche Mehrwert liegt in der Stimmungskurve. Wenn ihr die Hochs und Tiefs des Teams neben die Ereignisse legt, die sie ausgelöst haben, seht ihr, wie die Energie im Projektverlauf gestiegen und gesunken ist: der Launch, der alle beflügelt hat, die Umstrukturierung, die die Stimmung einen Monat lang gedrückt hat, die späte Scope-Änderung, mit der niemand gerechnet hatte. Es zeigen sich Muster, die man bei einer Betrachtung Sprint für Sprint übersehen würde, und wer erst mittendrin dazugekommen ist, erfährt die Teile der Geschichte, die er verpasst hat. In TeamRetro umfasst die Vorlage für die Timeline-Retrospektive vier Themen: wichtige Ereignisse, Höhepunkte, Tiefpunkte und Lehren für das nächste Mal. Die Teilnehmenden sammeln zunächst jeder für sich Ideen, dann gruppiert das Team zusammengehörige Beiträge, stimmt über die wichtigsten ab und vereinbart zum Abschluss Maßnahmen mit namentlich benannten Verantwortlichen. Das Format braucht genug Vorgeschichte, also hebt es euch für das Ende eines Projekts, Quartals oder Jahres auf. Für einen zweiwöchigen Sprint lohnt es sich nicht, da fahrt ihr mit einem einfacheren Format besser.

Format der Timeline-Retrospektive

Wichtige Ereignisse

Was ist passiert, und ungefähr wann? Ein Ereignis pro Idee.

Wichtige Ereignisse sind die Fakten der Geschichte: Releases, Entscheidungen, Leute, die dazukommen oder gehen, Vorfälle, Deadlines und Richtungswechsel. Bitte alle, pro Idee ein Ereignis einzutragen und jedes mit einem ungefähren Datum oder einer Woche zu beginnen („Mitte März“, „Woche 6“), damit das Team sie ordnen kann. Schick ein paar Tage vor der Session eine Erinnerung, in der du die Leute bittest, ihre Kalender, Release Notes, Tickets und Chatverläufe durchzusehen. Erinnerungen verblassen schnell, und ohne diese Vorbereitung verdrängen die letzten Wochen die frühen. Wenn die ersten Monate beim Aufdecken der Ideen dünn aussehen, sprich das an und gib den Leuten ein paar Minuten, um die Lücke zu füllen.

Höhepunkte

Wann war das Team in Bestform, und warum?

Höhepunkte sind die Momente, in denen Energie, Zuversicht oder Stimmung am höchsten waren. Bitte die Leute, jeden Höhepunkt mit einem Datum oder einem wichtigen Ereignis zu verknüpfen und zu beschreiben, wie er sich angefühlt hat, nicht nur, was passiert ist. „Die Beta auszuliefern war nach Wochen voller Zweifel eine riesige Erleichterung“ sagt dir mehr als „Beta ausgeliefert“. Achte darauf, was die Höhepunkte gemeinsam haben, etwa klare Ziele, gute Zusammenarbeit oder sichtbare Fortschritte, denn genau diese Bedingungen lohnt es sich im nächsten Projekt wieder herzustellen.

Tiefpunkte

Wann hatte das Team zu kämpfen, und warum?

Tiefpunkte sind die Momente, in denen die Energie absackte: Frust, Stress, Verwirrung oder Erschöpfung. Bitte die Leute, sie zu datieren und zu sagen, wie sie sich gefühlt haben, und erinnere die Gruppe daran, dass es darum geht zu verstehen, was passiert ist, nicht darum, Schuld zuzuweisen. Manchen fällt es schwer, Tiefpunkte vor einer Führungskraft zu benennen, daher hilft hier das anonyme Brainstorming in TeamRetro. Prüft in der Diskussion, ob die Einbrüche mit bestimmten Ereignissen zusammenfallen. Wiederkehrende Tiefs rund um Scope-Änderungen oder Übergaben deuten meist auf ein Prozessproblem hin, für das sich eine Maßnahme lohnt.

Lehren für das nächste Mal

Was würden wir beim nächsten Projekt wiederholen oder ändern?

Bei den Lehren wird aus der Timeline eine Grundlage für Entscheidungen. Bitte die Leute, Höhe- und Tiefpunkte gemeinsam zu betrachten und vorzuschlagen, was sie beim nächsten Projekt beibehalten und was sie ändern wollen. Dränge auf konkrete Vorschläge: „Beim Kickoff mit dem Kunden einen Änderungsprozess vereinbaren“ lässt sich umsetzen, „Besser kommunizieren“ nicht. Sobald die Ideen gruppiert sind und abgestimmt wurde, mach aus den zwei oder drei wichtigsten Maßnahmen in TeamRetro, jeweils mit namentlich benannter verantwortlicher Person und Fälligkeitsdatum, damit die Lehren in die nächste Arbeit einfließen.

Wann sollte diese Retrospektive durchgeführt werden?

  • Am Ende eines Projekts oder eines großen Releases, wenn das Team vor dem nächsten Schritt auf die gesamte Arbeit zurückblicken möchte.
  • Für Quartals- oder Jahresrückblicke, wenn es genug Ereignisse und genug Höhen und Tiefen gibt, um eine klare Stimmungskurve zu zeigen.
  • Wenn Leute mittendrin dazugekommen oder gegangen sind und das Team ein gemeinsames Bild davon braucht, was passiert ist und warum.
  • Nach einer langen oder schwierigen Arbeitsphase, um zu verstehen, was dem Team Energie geraubt und was es beflügelt hat.
  • Vor dem Start eines ähnlichen Projekts, um Lehren zu sammeln, auf die das neue Team aufbauen kann. Für einen zweiwöchigen Sprint lohnt sich das Format nicht.

Vorschläge für Fragen zum Icebreaker

  • Wenn dieses Projekt ein Film wäre, wie würde er heißen?
  • Welcher kleine Moment aus diesem Projekt hat dich zum Lachen gebracht?

Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →

Ideen und Tipps für Ihre Retrospektive

  • Schick ein paar Tage vor der Session eine Erinnerung, in der du die Leute bittest, ihre Kalender, Release Notes, Tickets und Chatverläufe durchzusehen. Ohne diese Vorbereitung schlägt der Recency Bias zu, und die letzten Wochen dominieren die Timeline.
  • Bitte alle, jede Idee mit einem ungefähren Datum oder einer Woche zu beginnen. Datierte Ideen lassen sich viel leichter ordnen und gruppieren, und sie machen das Auf und Ab der Teamstimmung sichtbar.
  • Ermutige die Leute, neben dem, was passiert ist, auch zu sagen, wie sich jedes Ereignis angefühlt hat. Gerade die emotionale Seite unterscheidet eine Timeline von einem Projektstatusbericht.
  • Nutze anonymes Brainstorming, damit die Leute Tiefpunkte ehrlich benennen können, besonders wenn Führungskräfte oder Stakeholder dabei sind. Halte die Diskussion bei Ereignissen und Rahmenbedingungen, nicht bei einzelnen Personen.
  • Plane mehr Zeit ein als für eine normale Sprint-Retro. Ein langes Projekt hat viel Vorgeschichte, rechne also mit 60–90 Minuten und setze für jedes Thema eine Timebox, damit die Lehren am Ende nicht zu kurz kommen.
  • Schließe mit wenigen Maßnahmen ab, jeweils mit namentlich benannter verantwortlicher Person und Fälligkeitsdatum. Geht sie zu Beginn des nächsten Projekts noch einmal durch, damit die Lehren auch umgesetzt werden.

Häufig gestellte Fragen

Was ist eine Timeline-Retrospektive?
Eine Timeline-Retrospektive ist ein Format, bei dem das Team die wichtigsten Ereignisse eines Projekts, Quartals oder Jahres in zeitlicher Reihenfolge festhält und dann die Höhe- und Tiefpunkte ergänzt, die es dabei erlebt hat. Der Vergleich von Ereignissen und Teamstimmung zeigt, was geholfen und was geschadet hat, und die Session endet mit vereinbarten Maßnahmen.
Wie lange dauert eine Timeline-Retrospektive?
Die meisten Timeline-Retrospektiven dauern 60–90 Minuten, je nach Teamgröße und Länge des betrachteten Zeitraums. Ein Jahresrückblick mit einem großen Team kann eher zwei Stunden brauchen.
Kann ich eine Timeline-Retrospektive für einen Sprint nutzen?
Für einen zweiwöchigen Sprint lohnt sie sich nicht. Es gibt zu wenige Ereignisse und zu wenig Schwankung in der Stimmung, daher bringt dir ein einfacheres Format wie Start, Stop, Continue in kürzerer Zeit mehr.
Worin unterscheidet sich eine Timeline-Retrospektive von einem Post-Mortem?
Eine Timeline deckt den gesamten Bogen eines Projekts ab, Gutes wie Schlechtes, und betrachtet, wie sich das Team im Verlauf der Ereignisse gefühlt hat. Ein Post-Mortem untersucht meist nach einem Vorfall oder Fehlschlag, was schiefgelaufen ist, um die Ursachen zu finden.
Wie verhindere ich, dass sich alle nur an die letzten Wochen erinnern?
Bitte die Teilnehmenden, vor der Session Kalender, Release Notes, Tickets und Chatverläufe durchzusehen. Weise während des Brainstormings auf dünn besetzte Abschnitte der Timeline hin und gib den Leuten ein paar Minuten, um Ereignisse aus diesem Zeitraum zu ergänzen.
Warum sollten Ideen mit einem Datum versehen werden?
Mit Datumsangaben kann das Team die Ereignisse ordnen und Höhe- und Tiefpunkte dem gegenüberstellen, was zu der Zeit gerade passiert ist. Durch diese Gegenüberstellung erkennt ihr Muster, zum Beispiel dass die Stimmung nach jeder Scope-Änderung einbricht.
Sind Sie bereit, diese Retrospektive durchzuführen?Probieren Sie diese Retrospektive live aus