Höchster ROI

In welchen Bereichen hatten wir den höchsten ROI?

Unser neuer Code-Review-Prozess hat die Deployments spürbar beschleunigt.
Das Pairing bei dem komplexen Feature hat sich gelohnt, wir waren sogar vor dem Zeitplan fertig.
Im Trainings-Workshop haben wir Fähigkeiten gelernt, mit denen wir das Altsystem viel schneller refaktorisieren konnten.
Niedrigster ROI

In welchen Bereichen hatten wir den niedrigsten ROI?

Wir haben zu viel Zeit mit Architekturdiskussionen verbracht, ohne einen klaren Rahmen für Entscheidungen.
Die ständigen Kontextwechsel zwischen Projekten haben uns echt ausgebremst.
Unklare Anforderungen haben zu Nacharbeit geführt, die unseren Fortschritt insgesamt geschmälert hat.
Potenzieller ROI

Wo können wir unseren ROI verbessern?

Wenn wir mehr Tests automatisieren, bekommen wir schneller Feedback und müssen Änderungen weniger manuell prüfen.
Mehr gemeinsame Workshops könnten uns helfen, Probleme als Team schneller zu lösen.
Wenn wir uns mehr Zeit für Wissensaustausch nehmen, verteilt sich das Know-how und wir hängen nicht an ein oder zwei Leuten.

Was ist die Rate-of-Improvement-Retrospektive?

Die Rate-of-Improvement-Retrospektive (ROI) fragt, wo der Einsatz eures Teams den größten Fortschritt gebracht hat und wo nicht. Der Name spielt auf Return on Investment an: Statt um Geld geht es darum, wie viel Verbesserung das Team für die investierte Zeit und Energie zurückbekommen hat. Das Board hat drei Spalten. „Höchster ROI“ ist für die Bereiche, in denen sich der Aufwand schnell ausgezahlt hat, etwa eine automatisierte Testsuite, die die Zeit für Bugfixes verkürzt hat, oder ein Planungsformat, das die Lieferung planbarer gemacht hat. „Niedrigster ROI“ umfasst Aufwand, der nichts vorangebracht hat, zum Beispiel lange Architekturdebatten ohne Entscheidung oder ständige Kontextwechsel. „Potenzieller ROI“ blickt nach vorn und fragt, wo sich eine Veränderung als Nächstes auszahlen würde. Weil das Format dazu auffordert, Erträge zu vergleichen, funktioniert es am besten mit Belegen: Cycle Time, Durchsatz, Escaped Defects oder alles andere, was euer Team ohnehin misst. Setzt es ein, wenn sich der Fortschritt langsam anfühlt, nach einem großen Projekt oder als regelmäßigen Check neben euren üblichen Retrospektiven. Macht zum Schluss aus den vielversprechendsten Ideen unter „Potenzieller ROI“ Maßnahmen mit einer verantwortlichen Person.

Format der Rate-of-Improvement-Retrospektive

Höchster ROI

In welchen Bereichen hatten wir den höchsten ROI?

Schaut darauf, wo das Team im letzten Zeitraum für seinen Einsatz den größten Fortschritt erzielt hat. Fragt nach konkreten Beispielen und, wo möglich, nach Zahlen, die sie belegen. Wenn ihr versteht, warum diese Maßnahmen funktioniert haben, wisst ihr, wovon ihr mehr machen solltet.

Niedrigster ROI

In welchen Bereichen hatten wir den niedrigsten ROI?

Findet die Bereiche, in denen der Aufwand nicht zu echtem Fortschritt geführt hat. Fragt nach dem Warum: War es das falsche Problem, der falsche Ansatz oder etwas, das das Team nicht beeinflussen kann? Diese Engpässe zu benennen ist der erste Schritt, um zu entscheiden, ob ihr sie behebt oder keine Zeit mehr hineinsteckt.

Potenzieller ROI

Wo können wir unseren ROI verbessern?

Blickt nach vorn: Wo könnte das Team für seinen Einsatz mehr Verbesserung herausholen? Mutige Ideen sind willkommen, aber fragt nach, was dafür spricht, dass sich die jeweilige Idee auszahlt. Macht aus den vielversprechendsten Ideen Maßnahmen mit einer verantwortlichen Person und einem Termin.

Wann sollte diese Retrospektive durchgeführt werden?

  • Wenn das Team das Gefühl hat, dass der Fortschritt in manchen Bereichen stockt oder sich verlangsamt hat
  • Nach einem großen Projekt oder einer größeren Initiative, um zu sehen, welche Maßnahmen sich ausgezahlt haben
  • Alle paar Monate neben euren üblichen Retros, um zu prüfen, wohin der Aufwand für Verbesserungen fließt
  • Wenn sich Strategie oder Prioritäten ändern und das Team überdenken sollte, wofür es seine Zeit für Verbesserungen einsetzt

Vorschläge für Fragen zum Icebreaker

  • Wenn unser Team ein Fahrzeug wäre, welches wäre es und warum?
  • Welche neue Fähigkeit hast du dir kürzlich angeeignet, mit der du schneller arbeitest?

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

  • Bringt Kennzahlen wie Cycle Time, Durchsatz und Escaped Defects mit, damit Aussagen über hohen oder niedrigen ROI auf Belegen beruhen
  • Verwechselt hohen Aufwand nicht mit niedrigem ROI: Manche schwierigen Probleme brauchen mehr Investition, bevor sie sich auszahlen
  • Sorgt dafür, dass man gefahrlos zugeben kann, wenn etwas nicht funktioniert hat, sonst bleibt die Spalte „Niedrigster ROI“ leer
  • Macht aus den besten Ideen unter „Potenzieller ROI“ Maßnahmen mit einer verantwortlichen Person
  • Nutzt das Format ergänzend zu Formaten, die Prozesse, Zusammenarbeit oder technische Praktiken betrachten, nicht als Ersatz dafür

Häufig gestellte Fragen

Was ist eine Rate-of-Improvement-Retrospektive?
Eine Retrospektive mit drei Spalten, in der euer Team betrachtet, wo der Aufwand für Verbesserungen den höchsten Ertrag gebracht hat, wo den niedrigsten und wo er sich als Nächstes auszahlen könnte. Ziel ist es, mehr Einsatz in die Veränderungen zu stecken, die funktionieren.
Bedeutet ROI in dieser Retrospektive Return on Investment?
Hier steht ROI für Rate of Improvement, also wie viel Fortschritt das Team für seinen Einsatz bekommen hat. Das Format übernimmt die Idee eines Ertrags, es wird aber nichts finanziell berechnet.
Wie führt man eine Rate-of-Improvement-Retrospektive durch?
Teilt zuerst relevante Kennzahlen, dann schreiben alle für sich Notizen in die drei Spalten. Besprecht die höchsten und niedrigsten Erträge, stimmt über die Ideen unter „Potenzieller ROI“ ab und macht aus den ein oder zwei wichtigsten Maßnahmen.
Wann sollte ich eine Rate-of-Improvement-Retrospektive einsetzen?
Wenn der Fortschritt zu stocken scheint, nach einem großen Projekt, alle paar Monate als Check, wohin der Aufwand für Verbesserungen fließt, oder wenn eine geänderte Strategie bedeutet, dass das Team seine Prioritäten überdenken sollte.
Brauchen wir Kennzahlen dafür?
Nein, aber sie helfen. Schon ein paar Zahlen wie Cycle Time oder die Zeit für Bugfixes verhindern, dass die Diskussion zu einem Wettstreit der Meinungen wird.
Sind Sie bereit, diese Retrospektive durchzuführen?Probieren Sie diese Retrospektive live aus