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.