+1 Punkt
in Agiles Projektmanagement von
Diese Frage höre ich oft von Scrum-Mastern. Sie setzen Retrospektiven auf, die Teilnehmer kommen alle (oder die Meisten) und wenige sagen was. Vielen Teilnehmern scheint es nicht wichtig zu sein an der Retrospektive teilzunehmen oder empfinden sie als overhead. Was ist in so einem Fall zu tun? Habt Ihr auch ähnliche Erfahrungen gemacht?

4 Antworten

0 Punkte
von
ausgewählt von
 
Beste Antwort
Das kenne ich auch. Die Gründe dafür können natürlich ganz verschieden sein. Teilnehmer sind vielleicht zu schüchtern, zu frustriert und glauben es hilft sowieso nichts oder aber glauben es läuft super, da gibt es nichts zu reflektieren, haben vielleicht auch einfach einen schlechten Tag und wollen sich lieber ausklinken oder eben etwas ganz anderes. Generell finde ich es wichtig als Scrum Master Raum für jeden zu schaffen, zu Wort zu kommen und gehört zu werden. Schon ein sogenannter "Icebreaker" kann hier hilfreich sein. Irgendeine kurze Aktion zum Einstieg, wodurch jeder zu Wort kommt und einmal etwas sagt. Das erste Wort ist häufig das schwierigste. Ich persönlich hole in der Regel auch die Teilnehmer gerne direkt ab, von denen ich das Gefühl habe, da kam noch nichts. Ich spreche dann einfach an und Frage nach entsprechendem Input. Wenn die ganze Gruppe natürlich kaum etwas sagt, fehlt vielleicht einfach eine Aktion die Bewegung in die Sache bringt und auch einfach Spaß macht. Gerade die Retrospektiven bieten eine tolle Spielwiese für unterschiedliche agile Aktionen, die Kommunikation fördern und Teilnehmer zwangsläufig involvieren. Sollte so etwas allerdings nicht besser werden, könnte man auch dieses Problem vielleicht einmal zum Thema einer Retrospektive machen.
von
Bearbeitet von
Bei wiederholten Problemen mit einzelnen Teammitgliedern helfen nach meiner Erfahrung auch Einzelgespräche, um nähere Gründe hinsichtlich deren Denken, Fühlen, Verhalten und Umfeld (z.B. persönliche Probleme mit Teammitgliedern) zu erfahren. Ich gehe in solchen Gesprächen dann nach dem systemischen Coaching Ansatz / fragend vor.
0 Punkte
von

Ich setze bei Retrospektiven mit bereits offenen wie auch noch zurückhaltenden Mitarbeitern häufig auf die im Buch Making Good Teams Great beschriebene Struktur.

Beim ersten Punkt (Set the Stage) hilft mir dabei, die Retrospektive mit dem Austeilen von Süssigkeiten zu beginnen, um die Leute mental durch Zucker aufzulockern. Dazu schaffe ich dann mit der Vegas Regel einen sicheren Rahmen:

„What happens in Vegas, stays in Vegas“

So frage ich die Teilnehmer nach ihrem Commitment dafür, ob alles was in der Retro besprochen wird, auch unter den Teilnehmern bleibt, außer alle beschließen gemeinsam, dass bestimmte Aspekte nach außen getragen werden.

Darüber hinaus nutze ich als Material Moderationskarten und Postits, damit auch stille Teilnehmer ausreichend Zeit und Gelegenheit haben, ihre Gedanken zu positiven wie negativen Aspekten aufzuschreiben. Bei sehr stillen Teams biete ich zudem in den ersten Retros an, die Karten in einen Kasten anonym zu werfen. Stück für Stück trainiere ich mit den Teams aber offen zueinander zu sein, z.B. durch einen Workshop zur Stärkung des agilen Mindsets sowie tägliche Daily Standup Meetings.

Quelle:

https://www.amazon.de/dp/B00B03SRJW?ref_=cm_sw_r_kb_dp_wVY0CbGEZZJ3S&tag=kp0508-21&linkCode=kpe

0 Punkte
von
Man kann auch eine Retrospektive machen, in der nicht unbedingt gesprochen werden muss. Somit kann man introvertierten Charakteren durchaus auch eine Stimme verleihen.
Dies kann man z.B. durch mit Mitteln wie Lego, Knette oder Bastelmaterial. Damit sollen die Teilnehmer dann die vergangene Retro darstellen, welche Maßnahmen sie sehen usw.
Man kann auch ein Theaterspiel machen und zusammen spielt man den letzten Sprint nach.

Wenn man merkt, dass den Teilnehmern die Retrospektive nicht wichtig ist, sollte man noch einmal durchsprechen, warum denjenigen die Retro nicht wichtig ist. Das kann man durchaus auch als Aufhänger der Retrospektive machen. Das Motto der Retro ist dann "Warum machen wir eine Retrospektive"
0 Punkte
von
Wenn die Teilnehmer wenig Interesse an der Retrospektive haben, ist das zunächst erst einmal ein Zeichen, dass irgendetwas nicht stimmt. Es gibt offenbar Gründe, die den Wert der Retrospektive niedrig erscheinen lassen. Diese können viele sein:

Das Team findet zwar Lösungen, darf aber über diese nicht entscheiden. Also werden sie erst gar nicht angesprochen, weil niemand daran glaubt. Wenn z.B. dem Team klar ist, dass sie dringend mehr Testing-Skills benötigen, die über Teamumstrukturierungen erreicht werden könnten, über Teamrestrukturierungen aber nur auf Managementebene gesprochen wird und auch dort keine Entscheidungen fällen, führt das zu Frust. Ein klärendes Gespräch zw. Scrummaster und dem Management und das herausarbeiten von kulturellen Seiteneffekten kann helfen.

Vielleicht gibt es innerhalb des Teams Konflikte, die unter der Oberfläche schwelen, aber niemand traut sich in den offenen Konflikt zu gehen. Hier kann z.B. versucht werden, den Konflikt durch geeignete Maßnahmen erst einmal diskutierbar zu machen. Z.B. durch anonymes Abstimmen, ob es im Team ein Thema gibt, über das nicht gesprochen wird. Ein guter Ausgangspunkt, um ein Team, das sich gegenseitig nicht vertraut zu einem wirklich guten Team zu machen, sind die Ideen aus Patrick Lencionis Buch '5 dysfunctions of a team'.

Der Klassiker: Druck von außen auf das Team, man möge doch maximal viel Zeit einfach ins Coding stecken und nicht zu viel Zeit z.B. in der Retro verlieren (ja das gibt es!). Wenn es nicht möglich ist, insbesondere in der Führung ein Bewusstsein für die Wichtigkeit der Retrospektive zu generieren, dann habe ich gute Erfahrungen damit gemacht, dem Team entsprechende (von außen sichtbare) Probleme zu spiegeln, bereits Lösungsideen vorzubereiten und das Team muss nur noch abstimmen über Machen oder Nicht-Machen. Dies lässt sich in deutlich kürzerer Zeit durchführen, hat aber auch die Schwäche, dass es nicht besonders innovativ aus dem Team heraus ist und andere Ideen kaum Chancen haben, zum Zug zu kommen. Auf jeden Fall waren die Teammitglieder sehr froh, dass überhaupt etwas verändert werden konnte und gleichzeitig mussten sie sich nicht angreifbar machen, weil sie besonders viel Zeit in die Retro investiert haben. Dies kann aber nur als Übergangslösung dienen bis die Organisation gelernt hat, welches Potential in Retrospektiven steckt.

Ein weiterer Grund könnte sein, dass das Team sich überhaupt nicht als Team wahrnimmt, weil es lediglich eine Gruppe von Co-Workers bildet, in der jeder an anderen Aufgaben arbeitet. Es besteht kein gemeinsames Ziel, also besteht auch kaum ein Wunsch gemeinsam besser zu werden. Hier kann zunächst die Arbeit an den externen Bedingungen hilfreich sein. Ist der Product Owner in der Lage, ein starkes Ziel zu definieren, also Fokus zu geben. Oder versteht sich der Product Owner lediglich als Aufgabenverteiler und versucht den einzelnen Mitarbeiter in jedem Sprint bestmöglich auszulasten (Push-Prinzip). Das verhindert die Selbstorganisation und auch so kann kein Team zu einem wirklichen high performance Team werden. Die offen und etwas provokant gestellte Frage kann helfen: Warum dann überhaupt Teams, wenn die Vorteile eines Teamvorgehens nachrangig sind? Dies kann die richtige Diskussion anstoßen, in der dann auch über gruppendynamische Effekte usw. gesprochen kann, die dem Product Owner bewusst machen können, dass er selbst die Teamperformance beeinträchtigt.

Und zu guter Letzt: Ist man selbst der richtige Scrummaster für dieses Team? Vertraut das Team mir? Spricht es offen mir gegenüber oder eben nicht (siehe Eingangsfrage)? Gab es vielleicht Ereignisse in der Vergangenheit, die dieses Vertrauen beschädigt haben? Auch hier kann es helfen, diesen Punkt offen anzusprechen, wenn man eine gewisse Reserviertheit gegenüber dem Scrummaster (also sich selbst) spürt. Hier und da habe ich vorbeugend auch einmal eine Retrospektive über den Scrummaster (also mich selbst) mit dem Team gemacht. Wo hat der Scrummaster gut unterstützt? Wo war das Team enttäuscht? Wo hat der Scrummaster regelrecht genervt? Damit erhält man wertvolles Feedback, wie man sein Team noch besser unterstützen kann. Wichtig: Man muss auch offen dafür sein, dass die Chemie zw. Scrummaster und Team vielleicht nicht (mehr) passt. In diesem Falle ist ein Wechsel des Scrummasters durchaus eine Option.
Teamprove Wissen – die OnlineCommunity für agile Unternehmen

Wir bieten agilen Einsteigern und Experten eine Q&A-Plattform zum Austausch mit Gleichgesinnten – von Organisationsentwicklung und Leadership über agile Methoden und Remote Work bis hin zu Innovationsmanagement.
...