Die Retrospektive: Mehr als nur ein Ventil für Frust

Die Sprint-Retrospektive ist ein zentraler Bestandteil von Scrum und gibt deinem Team die Möglichkeit, die Zusammenarbeit zu reflektieren und sich kontinuierlich zu verbessern. Doch was passiert, wenn die Erwartungen an die Retro so festgefahren sind, dass ihr eigentlicher Zweck – Lernen und Wachsen – in den Hintergrund rückt? Diese Frage beschäftigt mich immer wieder, da ich als Scrum Master regelmäßig mit unterschiedlichen Bedürfnissen und Vorstellungen innerhalb meines Teams konfrontiert werde.

In meinen Retros versuche ich, kreative und individuelle Formate einzusetzen, um neue Perspektiven zu eröffnen und tiefere Einsichten in die Herausforderungen des Teams zu gewinnen. Kürzlich habe ich zum Beispiel eine Retro mit einer Kennenlernrunde kombiniert, um einen neuen Entwickler besser ins Team zu integrieren. Während einige diese Idee gut fanden, äußerten andere Unzufriedenheit, da sie sich nicht ausreichend auf den vergangenen Sprint konzentrieren konnten. Das Feedback war eindeutig: „Können wir nicht eine richtige Retro machen?“ Dieser Kommentar hat mir gezeigt, wie unterschiedlich die Erwartungen an eine Retrospektive sein können.

Einige Teammitglieder betrachten die Retro leider als Raum, um ihre Unzufriedenheit mit dem letzten Sprint anzusprechen. Natürlich ist es wichtig, Probleme anzusprechen, doch das allein greift zu kurz. Laut Scrum Guide ist die Retrospektive nicht strikt definiert – sie ist ein Raum für Reflexion und Verbesserung auf allen Ebenen: Prozesse, Zusammenarbeit, Tools und mehr. Wenn wir die Retro nur als Ventil für Frustration nutzen, verlieren wir den Blick für das große Ganze. Probleme sollten jederzeit im Sprint angesprochen werden können, nicht erst am Ende. Andernfalls stauen sich negative Emotionen auf und können eskalieren.

Eine gute Retrospektive lebt von einem ausgewogenen Ansatz. Sie sollte sowohl Raum für akute Probleme bieten als auch langfristige Verbesserungen im Blick behalten. Als Scrum Master sehe ich es als meine Aufgabe, das Team dabei zu unterstützen, diese Balance zu finden. Individuelle Formate können helfen, eingefahrene Denkmuster aufzubrechen und neue Impulse zu setzen – aber nur, wenn das Team offen dafür ist.

• Klare Kommunikation der Ziele: Zu Beginn jeder Retro sollte das Ziel des Meetings klar definiert werden. Geht es um akute Probleme oder langfristige Verbesserungen? Oder beides?
• Feedback ernst nehmen: Die Feedbackrunde am Ende hilft mir zu verstehen, was gut ankam und was nicht – aber auch hier braucht es Offenheit von beiden Seiten.
• Probleme frühzeitig adressieren: Teams sollten ermutigt werden, Herausforderungen direkt im Sprint anzusprechen, statt sie bis zur Retro aufzustauen.
• Flexibilität bewahren: Standardformate wie „Mad-Sad-Glad“ oder „Starfish“ sind hilfreich, aber gelegentliche Abwechslung kann frischen Wind in die Diskussion bringen.
• Schwerpunkte setzen: Retros können gezielt thematisch ausgerichtet werden, um bestimmte Aspekte intensiver zu beleuchten. Zum Beispiel könnte eine Retro der Zusammenarbeit mit Fachabteilungen gewidmet sein, während eine andere die Codequalität in den Fokus rückt.
• Fokus auf das große Ganze: Neben Sprint-bezogenen Themen sollten auch teamübergreifende oder prozessuale Aspekte reflektiert werden.

Die Retrospektive ist viel mehr als nur ein Event zum Dampfablassen – sie ist ein Werkzeug für kontinuierliche Verbesserung und ein Katalysator für Veränderungen im Team. Um ihren vollen Wert auszuschöpfen, musst du dich von starren Erwartungen lösen und bereit sein, neue Wege zu gehen. Mein Ziel bleibt es, Retrospektiven so zu gestalten, dass sie sowohl kurzfristige Probleme lösen als auch langfristig das Team stärken.

Wie siehst du das? Was macht für dich eine wirklich gute Retrospektive aus? Hast du schon ähnliche Herausforderungen erlebt? Lass mich deine Gedanken in den Kommentaren wissen.