Feedback umsetzen in 3 Schritten – Retrospektiven wirkungsvoll gestalten #3

Das Ergebnis der (Sprint-)Retrospektive sollten Verbesserungsvorschläge sein, die der ScrumMaster mit in das Impediment Backlog aufnimmt bzw. sorgt er dafür, dass diese Impediments gelöst werden. Wie kann ich als ScrumMaster erreichen, dass Vorschläge, auf die das Team sich committet, auch eingehalten werden und nicht als Post-Its oder „wir sollten mal…“-Vorschläge enden? Wie bringe ich mein Team dazu, zu agieren?Nachdem wir uns in der Blogreihe „Feedback in der Retrospektive“ damit auseinandergesetzt haben, welchen Rahmen es für gutes Feedback braucht und wie Schulz von Thuns Kommunikationsquadrat dabei helfen kann, geht es in diesem finalen Beitrag vor allem darum, „ins Tun zu kommen“.

1. In kleinen Schritten zum Ziel

Unabhängig davon, ob wir in einem agilen Umfeld arbeiten oder nicht, Dinge vor uns her zu schieben, ist etwas sehr Menschliches. Die einen arbeiten produktiver, wenn sie Zeitdruck haben. Die anderen schaffen es nicht, große Ziele in kleine, erreichbare Etappen aufzuteilen und gehen deshalb manche Dinge gar nicht erst an. Hier kann der ScrumMaster sein Team unterstützen, indem er darauf achtet, dass die konkreten Maßnahmen aus der Retrospektive kleine Schritte sind: Kleinigkeiten ändern, fällt uns viel leichter. Wenn ein Teammitglied z.B. wegen eingehender Emails und Anrufe schnell die Konzentration verliert, kann es helfen, erstmal 30 Minuten pro Tag als „Fokuszeit“ zu blocken (und sich daran zu gewöhnen, dass in dieser Zeit alle eingehenden Kontaktversuche auf stumm geschaltet sind), anstatt sich gleich mehrere Stunden abzukapseln.

2. Die Gründe erkennen, wenn das Team nicht ins Tun kommt

In agilen Umfeldern kann der Leistungsdruck hoch sein: Schließlich geht es darum, schnell und regelmäßig Inkremente zu liefern, die den Kunden zufriedenstellen bzw. ihm einen Mehrwert bieten. Bei der Umsetzung von Verbesserungsvorschlägen aus der Retrospektive scheitert es dann oft, weil die Teammitglieder gefühlt keine Zeit, zu viele Termine oder Verpflichtungen haben. Hier kann der ScrumMaster, gemeinsam mit dem Product Owner, das Team unterstützen: Wo kann umpriorisiert werden (sowohl im eigenen als auch im Produktbacklog)? Wie viel Zeit würde tatsächlich für die Umsetzung der Idee gebraucht? Welche kleinen Veränderungen kann das Team ohne hohen Zeitaufwand umsetzen? Welchen Mehrwert haben wir, wenn wir Maßnahme X vor Thema Y priorisieren?Es kann auch sein, dass ein Team das Gefühl hat, es bräuchte eine wirklich zündende Idee, und deshalb weiß niemand, wo anfangen. Hier kann der ScrumMaster das Team an den Deming-Zyklus erinnern, den es für Produkte sowieso durchläuft, wenn es nach Scrum arbeitet. Ebenso wie Produktideen geplant, umgesetzt, überprüft und angepasst werden, kann auch mit Prozessverbesserungen experimentiert werden: für ein bis zwei Sprints ausprobieren, in der folgenden Retrospektive kontrollieren und gegebenenfalls nachjustieren.

3. Ziele richtig formulieren

Eine Redewendung, die auch bei bg immer mal wieder auftaucht, lautet:

„Das Gras wächst nicht schneller, wenn man daran zieht.“

Als ScrumMaster kann man sein Team so gut wie möglich befähigen, aber gehen muss es selbst. Damit die ersten Schritte etwas leichter fallen, kann der ScrumMaster seinem Team dabei helfen, die Ziele klar zu formulieren. Stellt das Team z.B. in der Retrospektive fest, dass die Kommunikation in Meetings oft nicht wertschätzend ist, wird ein Ziel wie „Wir kommunizieren wertschätzender miteinander“ kaum zur Lösung beitragen.Es gilt: Ziele so konkret wie möglich formulieren! Was genau soll sich verändern? Was muss das Team dafür tun? Wie kann es feststellen, dass sich etwas geändert hat? Im Projektmanagement gibt es dafür die sogenannten „SMART“-Ziele. Die sind spezifisch (d.h. möglichst präzise), messbar, aktivierend (d.h. motivierend/erstrebenswert), realisitisch und terminiert. Eine Alternative zur Lösungsfindung kommt aus dem Design Thinking: Nutzen Sie als ScrumMaster die „Wie können wir…?“-Frage, um Wege zu finden, wie das Team ein Problem lösen könnte.

Führen Sie selbst eine Retrospektive durch

In dieser kleinen Blogreihe haben Sie erfahren, warum Feedback wichtig ist, wie man in einer Retrospektive einen entsprechenden Rahmen dafür schafft, auf welcher Kommunikationsebene Sie Teammitglieder verstehen und erreichen können und nun, wie Sie Ihre Teams ins Tun bringen. Ich wünsche Ihnen gutes Gelingen für Ihre eigene Retrospektive!Wenn Sie in einem Training lernen wollen, selbst wirkungsvolle Retrospektiven mit Ihrem Team durchzuführen, empfehle ich Ihnen das Inhouse Training Praxiswerkstatt Retrospektive.Eine besondere Art der Retrospektive, bei der wir Sie gerne unterstützen, ist die Corona-Retrospektive.

Die Reihe: Retrospektiven wirkungsvoll gestalten

#1 "Den geeigneten Rahmen für Feedback schaffen"

#2 "Feedback richtig entschlüsseln"

#3 "Feedback umsetzen in 3 Schritten"

Bild: Unsplash License, Brett Jordan

Agile Toolbox
Scrum
Scrum Meetings
Retrospektive
ScrumMaster-Praxistipps
Paulina Heins
August 4, 2020

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen