okr-framework

Review vs. Retrospektive, oder beides? Unterschiede und Gemeinsamkeiten

Inhaltsverzeichnis

Dank Home Office und Meeting Fatigue liegt der Gedanke nahe, Calls miteinander zu kombinieren oder gar zu streichen. Reviews und Retrospektiven sollten davon aber unberührt bleiben. Beide Formate finden am Ende einer Iteration statt und bieten agilen Teams und Unternehmen die Möglichkeit, sich kontinuierlich zu verbessern, um wettbewerbsfähig zu bleiben. Dennoch dienen sie unterschiedlichen Zwecken und werden daher nicht auf dieselbe Weise durchgeführt. Kurz gesagt geht es bei einem Review-Meeting um den Outcome, während sich eine Retrospektive auf den eigentlichen Prozess konzentriert, der zu diesem Outcome führt.


Zweck: ​Was ist der Grund für die Durchführung einer Review/Retrospektive?

Beide Methoden ermöglichen es Teams, schneller aus der Vergangenheit zu lernen und auf die sich stetig ändernden Marktbedingungen zu reagieren. Sie zeigen auf, wo Verbesserungen notwendig sind, machen aber auch deutlich, was Teams aus der letzten Iteration gelernt haben und würdigen Erfolge sowie Fortschritte.

Review:

Reviews sollen die Teams dazu befähigen, die Bedürfnisse der Kunden zuverlässiger zu erfüllen und die bestmöglichen Produkte und Dienstleistungen zu liefern. Die Teams besprechen ihre Ergebnisse, reflektieren aber auch Arbeitspensum und Vorbereitung und bringen neue Ideen ein.

Retro:

Eine Retrospektive hingegen zielt darauf ab, "das System zu verbessern" und eine bessere Zusammenarbeit und einen optimierten Prozess zu ermöglichen. Sie beleuchtet die Teamdynamik, die Verhaltensweisen, den Meeting-Rhythmus und das generelle Arbeitsumfeld.

Zeitpunkt und Dauer: Wann ist der richtige Zeitpunkt für eine Review/Retrospektive? Wie viel Zeit sollte für jedes dieser Meetings eingeplant werden?

Reviews und Retrospektiven finden am Ende einer Iteration, z. B. eines Scrum-Sprints oder OKR-Zyklus, statt. So kann sichergestellt werden, dass sich das Team noch an die wichtigsten Ereignisse erinnert und die gewonnenen Erkenntnisse sofort für die nächste Iteration heranziehen kann. Die Meetings sollten so angesetzt werden, dass sie ausreichend lang sind und zu einem passenden Zeitpunkt stattfinden; ein Freitagnachmittag könnte also weniger geeignet sein.

Review:

Die Teams analysieren ihre Arbeit zunächst in einer Review, bevor sie zu einer Retrospektive übergehen. Viele Teams nehmen sich eine halbe bis zwei Stunden Zeit für die Review. Vor allem nach der Einführung eines neuen agilen Frameworks wie OKR kann diese Reflexion über die eigene Leistung länger dauern.

Retro:

Aus einer Review ergeben sich oft relevante Themen für die anschließende Retrospektive. Die Erkenntnis, dass aufgrund unvorhersehbarer Ad-hoc-Aufgaben nicht alle Ziele erreichen konnten, könnte beispielsweise zu dem Schluss führen, dass das Team generell mehr Puffer im Voraus einplanen sollte. Die Retrospektive ist in der Regel kürzer, oftmals dauert sie nur eine halbe Stunde

Insights von Workpath: Bei Workpath haben wir die Erfahrung gemacht, dass es am effektivsten ist, wenn jedes Team seine Reviews und Retrospektiven zwei bis drei Wochen vor dem Ende eines OKR-Zyklus durchführt und dann die wichtigsten Ergebnisse mit unserem Program Lead teilt. Dieser Ansatz hilft uns, funktionsübergreifende und organisatorische Muster zu erkennen, die auf strukturelle Alignment-Probleme oder ähnliches hinweisen können. Diese gewonnenen Erkenntnisse werden dann mit den anderen Teams geteilt.

Teilnehmer: Wer sollte an einer Review/Retrospektive teilnehmen?

Um Transparenz und Alignment zu fördern, ist es wichtig, die richtigen Personen an Bord zu haben. Weder Reviews noch Retrospektiven sind dem Management überlassen, stattdessen sollen alle Teilnehmer (z. B. das Scrum-Team) um Feedback gebeten werden. Feedback folgt keiner Hierarchie: es ist in der Regel ausgesprochen wertvoll, verschiedene Perspektiven zu erwägen.

Review:

Da sich Reviews auf die erbrachte Leistung konzentrieren, sollten sie von allen durchgeführt werden, die an der Zielerreichung beteiligt waren. Unter Umständen schließt das Kunden oder andere Stakeholder ein. Im Falle von OKR kann es hilfreich sein, sich Feedback von anderen Teams einzuholen, die ebenfalls auf ein bestimmtes Objective oder Key Result hingearbeitet haben.

Retro:

Retrospektiven können über vertrauliche Details wie Kommunikationsbarrieren oder verletzte Gefühle informieren. Um tatsächlich nützliche Erkenntnisse zu gewinnen und Prozesse effektiv zu verbessern, müssen sich die Teilnehmer sicher fühlen und ihre Gedanken offen mitteilen können. Daher kann es hilfreich sein, Retrospektiven in einer kleineren Gruppe zu organisieren. In der Regel werden alle Mitglieder einbezogen, die an der letzten Iteration teilgenommen haben.

Agenda: Was ist die richtige Struktur für eine Review/Retrospektive?

Weder Reviews noch Retrospektiven sollen in destruktiver Kritik, hitzigen Diskussionen oder übereifrigen Planungssitzungen enden. Damit diese Meetings nicht abdriften, ist es hilfreich, die Teilnehmer zu bitten, sich vorzubereiten, und eine klare Struktur zu haben. Die Sitzungen sollten, z. B. von einem Team Lead, moderiert und koordiniert werden.

Review:

Die Review beginnt mit einer Begrüßung, die alle Teilnehmer auf den gleichen Stand bringt. Wenn möglich, werden die erzielten Resultate, wie Produktfunktionen, gezeigt oder erläutert, und es wird um Feedback von den Stakeholdern gebeten.
OKR-Teams können jedes Objective, seine Relevanz, den Fortschritt und die Ergebnisse diskutieren und die investierten personellen und finanziellen Ressourcen bewerten. Einige Teams benoten die Erreichung ihrer Ziele oder stufen sie anderweitig ein.

Insights von Workpath: Bei Workpath betrachten wir zunächst den Fortschritt unserer OKRs und hinterfragen dann, wie zufrieden das Team mit seiner Leistung ist. Diese zweite Frage soll die Eigenverantwortung des Teams betonen und die Herausforderungen und Lektionen des Quartals verdeutlichen. Der Grad der Zielerreichung allein ist oft nicht aussagekräftig genug, da er nicht unbedingt Aufschluss darüber gibt, wie das Team mit unvorhersehbaren Aufgaben oder Hindernissen umgegangen ist. Möglicherweise spiegelt er auch nicht die Relevanz und den Umfang eines Outcomes wider.

Retro:

Für die Retrospektive sollte eine Einleitung gewählt werden, die die Verantwortung der einzelnen Teammitglieder verdeutlicht und die richtige Atmosphäre für einen ehrlichen Austausch schafft. Manche Unternehmen stellen Teambuilding-Maßnahmen oder Icebreaker voran. Es sollte die Methode gewählt werden, mit der sich die Teilnehmer wohlfühlen.
Dann werden sowohl harte als auch weiche Faktoren, die auf die vergangene Iteration Einfluss hatten, gesammelt. Die Teilnehmer sollten ermutigt werden, Fakten und Gefühle zu teilen. Es bietet sich meist an, auch anonymes Feedback zu gestatten.
Diese Erkenntnisse können dann geclustert, nach Relevanz sortiert und/oder mit Hilfe von Methoden wie Punktesystemen nach Prioritäten geordnet werden.
Die Anliegen, die die meisten Stimmen erhalten haben, werden näher erörtert, um sie für die nächste Iteration zu verbessern. Es sollte keine Symptombehandlung sein, sondern Ursachen sollen direkt beseitigt oder mindestens abgeschwächt werden. Die Vorschläge aus dem Team sollten spezifisch und realisierbar sein.
Die Retrospektive endet mit einem Check-out, z. B. einer Feedback-Runde, damit die Teilnehmer die besprochenen Themen verinnerlichen und reibungslos an ihre Arbeit zurückkehren können.

Häufige Fehler

  1. Keine Vorbereitung

Sowohl der Moderator als auch die Teilnehmer sollten auf diese Meetings vorbereitet sein. Damit die Teammitglieder die vergangene Iteration gründlich reflektieren, hilft es, ihnen die Fragen und Themen im Vorfeld zur Verfügung zu stellen.

  1. Kein Engagement

Zunächst einmal sollten sich die Teammitglieder über die Bedeutung und Ziele beider Meetings im Klaren sein. Außerdem ist es hilfreich, die Sitzungen so zu strukturieren, dass unnötige Wiederholungen vermieden werden und auf natürliche Weise mehr Engagement gefördert wird, z. B. durch Icebreaker.

  1. Kein Kontext

Vor allem bei unternehmensweiten Meetings verstehen einzelne Mitarbeiter aus verschiedenen Abteilungen möglicherweise nicht die Relevanz aller Themen. Die Teams sollten daher nur die wichtigsten Erkenntnisse präsentieren, einen Kontext dazu liefern und Zeit für Nachfragen einplanen.

  1. Keine angemessene Atmosphäre

Reviews und Retrospektiven sind nicht dazu da, sich gegenseitig zu beschuldigen oder zu verurteilen. Destruktive Kritik zielt auf Vergangenes ab, während diese Meetings darauf ausgerichtet sind, die zukünftige Zusammenarbeit zu optimieren. Die Teams sollten ihren Fokus auf Lerneffekte legen. Selbst die größten Misserfolge führen oftmals zu wertvollen Learnings. Bei agilen Frameworks wie OKR geht es darum, Erkenntnisse zu gewinnen, sich kontinuierlich zu verbessern und Innovation voranzutreiben.

  1. Keine geeignete Unternehmenskultur

Die genannten Werte werden von der Organisation und den einzelnen Führungskräften vorgelebt. Manager müssen bereit sein, Feedback anzunehmen und größere Herausforderungen wie strukturelle Alignment-Probleme oder unzureichende Kapazitäten anzugehen. Vorschläge dürfen nicht danach beurteilt werden, von wem sie kommen, sondern wie sie dem Unternehmen und den übergeordneten Zielen dienen. Unternehmen müssen eine Lernkultur schaffen und ihren Mitarbeitern das Gefühl geben, dass sie Fehler zugeben und daran wachsen können.

Weitere Fragen

Welche Fragen sollten in einer Review/Retrospektive gestellt werden?

Die folgenden Fragen dienen lediglich als  Leitfaden: es können sowohl Fragen ausgelassen, als auch eigene hinzugefügt werden. Wie bei anderen agilen Praktiken und Methoden sind die jeweiligen Teams für ihren eigenen Prozess verantwortlich und können einen individuellen Fragenkatalog entwickeln. Die Antworten sollten anschließend innerhalb des Teams diskutiert werden.

Review:

  • Wie schätzen wir unsere Leistung generell ein?
  • Haben wir die richtigen Ziele verfolgt?
  • Was haben wir erreicht? Welchen Einfluss hatte unsere Arbeit?
  • Wie zufrieden sind wir mit dem Ergebnis?
  • Haben wir für jedes Ziel ausreichend Zeit eingeplant?
  • Haben wir für jedes Ziel ausreichend Ressourcen zur Verfügung gestellt?
  • Hatten wir die notwendigen Fähigkeiten, um unseren Teil zu erfüllen?
  • Haben andere Teams ausreichend Support geleistet?
  • Warum waren wir (nicht) erfolgreich bei der Erreichung unserer Ziele?
  • Was waren die größten Hindernisse und wie hätten sie verhindert werden können?
  • Was waren die größten Erfolgsfaktoren?
  • Haben wir unsere Ziele richtig priorisiert und diesen Fokus beibehalten?
  • Haben wir unsere Fortschritte kontinuierlich verfolgt und auf der Grundlage der gewonnenen Erkenntnisse Kurskorrekturen vorgenommen?
  • Waren wir und andere sich unserer/ihrer Verantwortung bewusst?
  • Haben wir Synergien genutzt?
  • Sind unsere Ziele noch immer relevant?
  • Werden sie auch in Zukunft Priorität haben?
  • Was haben wir gelernt?
  • Welche wichtigen Learnings aus dieser Iteration könnten für andere Teams relevant sein?
  • Wie können wir bessere Ziele für die nächste Iteration setzen?

Retro:

  • Wie haben wir uns (als einzelne Teammitglieder) während dieses Prozesses gefühlt?
  • Was waren unsere Stärken als Team in der vergangenen Iteration?
  • Wie können wir an unseren Schwächen für die nächste Iteration arbeiten?
  • Haben wir Kommunikationsbarrieren oder andere Probleme bei der Zusammenarbeit festgestellt?
  • Ist uns das Alignment negativ aufgefallen? Hat es zu Doppelarbeit geführt?
  • Haben wir uns während des gesamten Prozesses gegenseitig unterstützt?
  • Haben wir uns von anderen Teams unterstützt gefühlt?
  • Sind die übergeordneten Ziele sichtbar und relevant?
  • Verstehen wir alle den Zweck und die Techniken unseres Frameworks (wie OKR)?
  • Ist eine wöchentliche/monatliche/quartalsweise Planung für uns sinnvoll?
  • Was fehlt in unserem derzeitigen Set-up, um unsere Leistung zu steigern?

Sind Reviews und Retrospektiven zwingend notwendig?

Agile Methoden, wie OKR, verpflichten zu keinen starren Vorgaben, sondern liefern Orientierungshilfen und sollen von den Teams so angepasst werden, dass diese den größtmöglichen Nutzen daraus ziehen können. Mit anderen Worten: Die Durchführung von Reviews oder Retrospektiven ist nicht zwingend notwendig. Dennoch liefern beide Meetings den Teams wertvolle Informationen über ihre bisherige Leistung und öffnen überhaupt erst Türen, um diese weiter zu verbessern. Heutzutage ist es entscheidend, dass Organisationen schnell lernen und sich anpassen, um mit den wandelnden Marktbedingungen Schritt zu halten.
Wenn Teams zeitliche Schwierigkeiten haben, sowohl Reviews als auch Retrospektiven durchzuführen, empfiehlt es sich, diese Meetings zu verkürzen, anstatt sie gar nicht erst durchzuführen.

Wie oft sollte eine Review oder Retrospektive durchgeführt werden?

Damit die Formate Review bzw. Retrospektive ihr volles Potenzial entfalten und dem Team wertvolle Erkenntnisse liefern können, sollten sowohl Review als auch Retrospective idealerweise unmittelbar nach jeder Iteration und vor Beginn der nächsten durchgeführt werden. Je kürzer der Abstand zwischen den einzelnen Iterationen, desto leichter fällt es Teams und einzelnen Mitarbeitern, ihren Arbeitsfortschritt zu reflektieren. Damit nicht zu viel Zeit in Meetings investiert wird, bietet es sich an, die einzelnen Iterationen möglichst kurz zu halten und somit Überforderung und Zeitmangel vorzubeugen und stattdessen Learnings direkt umzusetzen. Wenn Reviews und Retrospektiven zu selten abgehalten werden, können sich Probleme in der Zusammenarbeit und persönliche Frustration aufbauen und somit der Unternehmenskultur nachhaltig schaden.
Schlussendlich gibt es jedoch keine Patentlösung: Teams sind stets selbst dafür verantwortlich eine gute Balance zwischen Arbeit und Reflexion zu finden und zu halten.