Die Retrospektive im agilen Prozess: No time to improve?

Wann ist eigentlich die Gelegenheit, mal über die Effektivität der Zusammenarbeit mit den Kollegen im Team zu sprechen oder Prozesse und Tätigkeiten in Frage zu stellen?

Wann haben Sie sich die folgenden oder ähnliche Fragen das letzte Mal gestellt oder sich getraut, sie 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 bringt das alles nichts mehr. Und ob das nächste Projekt mit demselben Team stattfindet und ob alle weiteren Rahmenbedingungen vergleichbar sind, bleibt offen.

Die Retrospektive: Inspect & Adapt

Als agiles Vorgehensmodell setzt Scrum dagegen auf regelmäßige Verbesserung schon während des Projektablaufs. Zum Ende jedes Sprints (fester Iterationszyklus von ein bis vier Wochen) ist ein "Verbesserungsmeeting" – die sogenannte Retrospektive – vorgesehen. Darin soll einem Scrum-Grundsatz Rechnung getragen werden: Inspect & Adapt. Das heißt: Wir betrachten regelmäßig unsere Zusammenarbeit kritisch und überlegen, welche Anpassungen wir vornehmen können, um noch besser und effektiver zusammenzuarbeiten.

Die Retrospektive ist ein fest vorgesehenes Meeting im Scrum-Framework. Ich würde es dabei als das wichtigste von allen bezeichnen, denn es ist das Instrument, das für die stetige Verbesserung des Teams und seiner Zusammenarbeit sorgt. Insbesondere für unerfahrene Scrum-Teams ist es wichtig, sich regelmäßig damit auseinandersetzen, wie gut sie mit dem Scrum-Prozess zurechtkommen. Typische Fragen, die das Meeting beantworten soll:

  • Wie zufrieden sind wir mit dem Ergebnis des letzten Sprints? Haben wir unsere Sprint-Ziele erreicht und wenn nein: Warum nicht?
  • Wie können wir die Zusammenarbeit im Team und auch mit dem Product Owner verbessern?
  • Wie können wir die Produktqualität optimieren?

Je nach Dauer der Iteration (Sprint) ist der Zeitbedarf für die Retrospektive unterschiedlich. Hat man sich im Projekt auf eine Sprintlänge von zwei Wochen geeignet, dann reichen meistens anderthalb bis zwei Stunden aus. Allerdings sollte man den Zeitbedarf mit dem Team klären. Dazu ist es sinnvoll, am Ende einer Retrospektive (siehe unten: Die Retrospektive der Retrospektive) nachzufragen: "Wie viel Zeit wollt Ihr Euch beim nächsten Mal nehmen?" Somit steckt das Team selbst den Zeitrahmen und kann sich darauf einstellen.

Ablauf: Die Phasen einer Retrospektive

Die Retrospektive folgt stets einem ähnlichen Ablauf, der sich in fünf Phasen unterteilen lässt.

Phase 1: Set the Stage
In dieser Phase der Retrospektive werden alle Beteiligten auf das Meeting eingestimmt und die Rahmenbedingungen erläutert. Wichtig ist hier, dass jeder Teilnehmer einen aktiven Beitrag leistet, um jeden einzelnen zu "aktivieren".

Eine weitere typische Anwendung ist außerdem die sogenannte Sicherheitsabfrage, die verdeckt beantwortet werden sollte: "Auf einer Skala von eins bis fünf: Wie frei meinst du in dieser Runde sprechen zu können?" Diese dient insbesondere auch dem Scrum Master dazu, ein Gefühl dafür zu bekommen, wie offen die Teilnehmer der Retrospektive tatsächlich miteinander umgehen.

Phase 2: Gather data
Diese Phase dient dazu, alle möglichen Informationen zum Betrachtungszeitraum (z.B. letzter Sprint) zu sammeln. Dabei können die Teilnehmer etwa danach gefragt werden, wie sie persönlich die Stimmung im Team oder auch den Verlauf des letzten Sprints empfunden haben. Als Beispiel sei hier eine sogenannte Sprint-Timelime angeführt.

Phase 3: Derive insights
Mit dieser Phase geht die Retrospektive in die aktive Verbesserung der Zusammenarbeit über. Aus den zuvor gesammelten Informationen soll das Team Verbesserungsvorschläge erarbeiten und diskutieren. Im einfachsten Fall geht das mit der Aktion "+/".

Beispiel-Aktion: +/ und der Blick nach vorne: Das Plus-Delta-Vorgehen besticht durch zwei Aspekte: Zum einen durch das explizite Ansprechen positiver Gesichtspunkte, zum anderen durch den Ansatz, lösungsorientiert zu arbeiten statt zu kritisieren. Natürlich ist es auch wichtig, sich der Stärken bewusst zu sein – umso schlimmer, dass wir quasi nie über sie sprechen. Kritik dagegen fällt uns viel leichter, bringt uns jedoch nur indirekt weiter. Plus-Delta zielt deshalb darauf ab, eine Kritik direkt in einen Verbesserungsvorschlag umzuwandeln, und kann bspw. so ablaufen:

  • Der Scrum Master bereitet ein Board mit zwei Spalten vor: "+" für Stärken/Positives und "" für Verbesserungsvorschläge.
  • Die Teilnehmer bekommen (fünf bis zehn Minuten) Zeit, auf Post-its Punkte für die beiden Spalten zu notieren.
  • Bei einer Teilnehmeranzahl von mehr als fünf kann das Team in mehrere Kleingruppen à zwei bis vier Personen aufgeteilt werden. Das hat den Vorteil, dass ggf. der Diskussionsbedarf eines Einzelnen nicht in der großen Gruppe behandelt werden muss, sondern vorab thematisiert wird.
  • Anschließend hängen die Teammitglieder die Zettel an das Board, jeder immer einen positiven Aspekt und einen Verbesserungsvorschlag im Wechsel. Dabei sollte man jeweils kurz erläutern, worum es geht, ohne jedoch Diskussionen über einzelne Punkte entstehen zu lassen.
  • Die entstandene Liste wird nun gemeinsam validiert und priorisiert. Das folgende Foto zeigt eine Priorisierung mithilfe von Klebepunkten:

Phase 4: Determine actions
Nun ist es an der Zeit, die gefundenen Lösungsvorschläge zu bewerten und zu priorisieren. Sich pro Iteration mehr als zwei bis drei Verbesserungen vorzunehmen, funktioniert selten – umso bedeutender ist es, die wichtigsten Dinge zuerst anzugehen. Übrigens ist es gerade für die Akzeptanz von Verbesserungsvorschlägen seitens des Teams wichtig, dass der Scrum Master den Beteiligten erklärt, dass die gefundenen Lösungen vorläufig sind und erst ausprobiert werden: "Lasst es uns bis zur nächsten Retrospektive testen, dann können wir es ggf. wieder rückgängig machen."

Phase 5: Close
Die letzte Phase der Retrospektive dient vor allem dazu, das Team mit einem guten Gefühl aus dem Meeting zu entlassen. Um das Meeting mit einer positiven Stimmung zu beenden – und weil wir überhaupt mit Lob viel zu sparsam sind! –, schlägt Esther Derby in ihrem Buch Agile Retrospectives eine Lobrunde vor, in der sich die Teilnehmer gegenseitig persönlich loben, und zwar mit wirklich ernstgemeintem Lob, das sich nicht pauschal auf das Team bezieht, sondern sich tatsächlich an einzelne Personen richtet.

Meine Erfahrung zeigt, dass Teams die Lobrunde beim ersten und zweiten Mal ungewohnt finden und den Mitgliedern das Loben schwerfällt, es jedoch schon nach der ersten Runde als positiv wahrnehmen. Esther Derby rät in diesem Zusammenhang, den Teilnehmern Zeit zu lassen und auch Phasen der Stille und des Nachdenkens nicht zu früh abzubrechen.

Um dem Team einen Einstieg in dieses Stadium der Retrospektive zu geben, kann der Scrum Master mit einem ernstgemeinten Lob an einen Teilnehmer beginnen: "Ich wollte Dich, Karl-Heinz, mal explizit dafür loben, dass Du in den Daily-Scrums stets die Prioritäten im Auge hast."

Die Retrospektive der Retrospektive
Um auch die Retrospektive selbst einem stetigen Verbesserungsprozess zu unterziehen, ist es sinnvoll, die Teilnehmer ganz am Ende der Retrospektive nach ihrem Eindruck zu fragen: "Empfandest Du das Meeting als sinnvoll oder als Zeitverschwendung?" Die schnellste Art der Abfrage ist dabei das ROTI-Prinzip (Return on time invested). Wir verwenden es in einer Fünfer-Skala und benennen die Punkte wie folgt:

  • --: Das Meeting war Zeitverschwendung.
  • 0: Die investierte Zeit spiegelt den Nutzen des Meetings wider.
  • ++: Das Meeting war sehr effizient und sinnvoll.

Ist die Bewertung weniger gut ausgefallen oder möchte man genauere Antworten erhalten, als diese pauschale Kurzabfrage hergibt, empfiehlt es sich, die Teilnehmer zusätzlich explizit nach positiven Elementen und Verbesserungsvorschlägen bezüglich der Retrospektive zu fragen (siehe Plus-Delta-Prinzip).

Fazit

Die Retrospektive ist meines Erachtens des Herzstück aller agilen Prozesse. Wenn wir nicht regelmäßig überprüfen und offen diskutieren, wie unsere Zusammenarbeit funktioniert, können wir unmöglich sicherstellen, dass das Team tatsächlich an einem Strang zieht und effektiv zusammenarbeitet.

Gerade für Teams, für die Frameworks wie Scrum oder Kanban neu sind und die noch Unsicherheit mit diesen Konzepten zeigen, ist es unerlässlich, sich kontinuierlich mit den gelebten Prozessen auseinanderzusetzen und auch Vorgehensweisen in Frage zu stellen.

Eine Retrospektive ist in meinen Augen sehr sinnvoll investierte Zeit und das letzte Scrum-Meeting, auf das ich verzichten könnte! Ich habe schon häufig am Sprint-Ende gedacht: "Es lief doch alles prima, eigentlich gibt’s gar nichts mehr zu besprechen." Und immer wieder hat mich die Retrospektive eines Besseren belehrt und mit wertvollen Ergebnissen überrascht.

In einer unserer jeden Donnerstag stattfindenden kostenlosen Live-Sessions zur Online-Beratung haben wir Nutzen und Ablauf von Retrospektiven ausführlich besprochen. Hier ist die Videoaufnahme:

Haben Sie Fragen zu agilen Vorgehensweisen? Möchten Sie Agilität in Ihrem Unternehmen einführen? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Mit mehr als 20.000 Stunden Projekterfahrung in internen und externen Projekten mit agilen Entwicklungsmethoden gehört //SEIBERT/MEDIA zu den erfahrenen und größten Anbietern für Scrum in Verbindung mit den Atlassian-Tools JIRA/Greenhopper und Confluence in Deutschland. Gerne helfen wir Ihnen bei der Etablierung agiler Prinzipien und Verfahren – sprechen Sie uns einfach unverbindlich an. Weiterführende Informationen finden Sie auch auf unserer speziellen Seite zum Thema Agilität in Unternehmen und auf unserer umfangreichen Seite Einstieg in die Software-Entwicklung mit //SEIBERT/MEDIA.

Weiterführende Informationen

Agile Projekte in der Praxis: Elemente, Nutzen, Tools, Hürden
Die Scrum-Meetings und ihre Bedeutung
Teambildungsprozesse in der Software-Entwicklung
Daily Standup-Meetings: Einsatzbesprechungen für effektive Teamarbeit
Greenhopper und JIRA: Agile Projekte digital abbilden

Quellen

Buch: Esther Derby - "Agile Retrospectives"
Agile Retrospective Wiki


Mehr über die Creative-Commons-Lizenz erfahren

Entdecke die Zukunft der agilen Transformation in der Automobilbranche beim Tools4AgileTeams at Scale "Automotive Day"!
ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

One thought on “Die Retrospektive im agilen Prozess: No time to improve?”

Schreibe einen Kommentar