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?
5 Antworten
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.
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.
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
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"
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"
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.
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.
Hallo zusammen (und hallo an mein früheres Ich),
ich antworte mir hier mal selbst, da mittlerweile einige Jahre vergangen sind und sich meine Sichtweise auf dieses Problem komplett gewandelt hat. Es ist viel passiert seit 2019 – wir haben uns verändert, die Arbeitswelt ist remote geworden, und Methoden, die damals funktioniert haben, reichen heute oft nicht mehr aus.
Wenn ich heute auf das Problem "Schweigen in der Retro" schaue, realisiere ich: Das Problem war oft nicht das Team, sondern mein Ansatz. Ich habe versucht, sofort auf die Meta-Ebene zu gehen ("Was lief schlecht?"), ohne dass das Team emotional dort war.
Was ich heute anders mache: Ich nutze kaum noch klassische "Frage-Antwort"-Runden zum Einstieg, sondern Simulationen.
Warum? Weil Schweigen oft Unsicherheit ist. Wenn wir aber gemeinsam ein kurzes Spiel spielen (z. B. 5 Minuten), bei dem wir gemeinsam scheitern oder gemeinsam gewinnen, ist das Eis sofort gebrochen. Die Emotionen sind wach, und man redet über das Spiel statt über sich selbst. Das ist viel sicherer.
Aus dieser Erkenntnis heraus haben wir eine Sammlung an Tools gebaut, die genau diese Brücke schlagen: games.teamprove.de
Wenn heute ein Team schweigt, lasse ich sie z. B. den "Traffic Jam" spielen. Danach redet jeder, weil sie sich über den Stau im Spiel aufregen. Und von da ist der Schritt zur Diskussion über unsere echte Arbeit nur noch winzig.
Vielleicht hilft dieses "Update aus der Zukunft" ja jemandem, der heute über diesen Thread stolpert.
Viele Grüße, Giancarlo