Langfristige Retrospektiven

Bild: Wikemedia Commons / Louis Moeller - Public Domain

Es ist eines der grossen Verdienste der agilen Frameworks (und im Besonderen von Scrum), dass sie mit den Retrospektiven einen regelmässig stattfindenden Rückblick-Termin auf die unmittelbar zurückliegende Vergangenheit etabliert haben. Erst durch sie wird Agilität im Sinn eines kontinuierlichen Inspect & Adapt möglich. Was in diesem Arbeitsmodus dagegen seltener stattfindet sind langfristigere Rückblicke. Schade eigentlich, denn langfristige Retrospektiven können in vielen Kontexten von Mehrwert sein. Hier sind einige von ihnen:

Zum Jahresende

Dieser Rhythmus macht vor allem da Sinn wo noch mit Jahresplanungen gearbeitet wird, deren Ergebnisse man gemeinsam unter die Lupe nehmen kann. Auch dort wo das nicht der Fall ist bietet es sich aber an, schliesslich ist der Jahreswechsel mit seinen Feiertagen eine Zäsur die sich für einen gemeinsamen Blick zurück anbietet. Im Normalfall sorgen diese Feiertage auch dafür, dass solche Retrospektiven nicht genau am Jahresende stattfinden sondern eher Mitte Dezember.

(Ungefähr) Halbjährlich

Der nächstkürzere Zeitraum, und direkt einer der etwas Anpassung und Erklärung benötigt. Auch im Sommer gibt es mit den Sommerferien, in denen die meisten Menschen in den Urlaub fahren, eine grosse Zäsur - allerdings liegen diese in der Regel bereits im dritten Quartal. In Kombination mit dem de facto-Ende des Arbeitsjahres vor Weihnachten ergibt sich so ein längerer Retrospektiv-Zeitraum im ersten Halbjahr und ein kürzerer im zweiten.

Quartalsweise

Nicht nur der wiederum nächstkürzere Zeitraum, sondern auch einer der sich (halboffiziell) in zwei agilen Frameworks wiederfindet. In den meisten Implementierungen des Scaled Agile Framework (SAFe) sind die mehrere Sprints umfassenden Pogramm Incremente drei Monate lang, genau wie die Zyklen in denen in der Regel mit Objectives and Key Results (OKRs) gearbeitet wird. Quartals-Retrospektiven können aber natürlich auch Framework-unabhängig sein.

Nach Ende eines (Teil-)Projekts

Die vermutlich älteste Variante langfristiger Retrospektiven, denn es handelt sich hier im Grunde um nichts anderes als um das im klassischen Projektmanagement schon seit langem übliche so genannte "Post Mortem". Aus diesem Namen ergibt sich auch das grösste Problem dieses Vorgehens: Erkenntnisse werden erst generiert wenn alles vorbei ist, womit eine Optimierung des laufenden Vorhabens nicht mehr möglich ist. Stattdessen lernt man hier für zukünftige Vorhaben.

Nach einem Go Live

Egal ob in der Produkt- oder in der Organisationsentwicklung, viele Unternehmen scheuen sich (aus guten und schlechten Gründen) davor regelmässige Veränderungen an einem laufenden System vorzunehmen. Verkaufsbeginne oder Umstrukturierungen finden dort erst statt wenn sich eine relevante oder kritische Menge angesammelt hat. Die dafür nötige Zeit kann immer wieder anders sein, weshalb es für solche Retrospektiven keinen festen Rhythmus gibt.

Zeitlich versetzt nach einem Go Live

Ähnlich, aber nicht ganz das gleiche. Der entscheidende Unterschied dieser Variante ist, dass auf etwas anderes zurückgeblickt wird. Im zuvor genannten Fall steht der Erstellungs-Zeitraum im Focus des Rückblicks, in diesem Fall sind es Erfolg und Akzeptanz der Ergebnisse bei Kunden und anderen Betroffenen. Es kann daher Sinn machen auch Vertreter dieser Gruppen einzuladen, falls mit Onsite Customern gearbeitet wurde ist das sogar sehr naheliegend.

Nach Übergabe eines Liefergegenstandes

Vor allem in Grossprojekten kommt es vor, dass Gewerke, Teilumfänge oder andere Arten von Liefergegenständen separat ausgeschrieben werden. Da diese Ausschreibungen während der gesamten Projektlaufzeit immer wieder stattfinden und in der Regel auch die selben Bieter an ihnen teilnehmen kann es hilfreich sein nach Übergabe eines Liefergegenstandes gemeinsam zu überlegen wie die Ausschreibung und Erbringung des nächsten Leistungspakets verbessert werden könnten.

Bei Bedarf

Anlässe für bedarfsgetriebene Retrospektiven gibt es viele, vom schlechter werdenden Betriebsklima über das Aufstauen technischer Schulden bis zu nachlassendem Erfolg am Markt. Erscheint einer von ihnen wichtig genug kann eine Retrospektive bei der Ursachenanalyse und Verbesserungsmassnahmen helfen. Ähnlich wie bei den Jenga-getriebenen Retrospektiven kann es auch Sinn machen zu warten bis genug Themen zusammengekommen sind, wenn die einzelnen für sich genommen zu unwichtig sind.

---

Natürlich ist diese Aufzählung nicht abschliessend, im Zweifel werden sich noch viele andere Möglichkeiten finden langfristige Retrospektiven zu planen und durchzuführen. Wichtig ist dabei vor allem, dass überhaupt Überlegungen dazu stattfinden ob und wenn ja auf welche Weise sie stattfinden sollten. Sobald sie erstmal etabliert sind kann man sie schliesslich so lange bedarfsgerecht anpassen bis sie ihren Zweck erfüllen. Mit kontinuierlichem Inspect & Adapt, wie eben in Retrospektiven üblich.