Die Fragen, die wir oben aufgezählt haben, dienen vor allem als erste Denkanstöße für die Teammitglieder. Der moderierende Scrum Master sollte die Kommentare später diskutieren lassen und weiter nachhaken. Unerfahrenen Moderatoren raten wir, Regeln für die Retro aufzustellen und sich das Commitment und die Unterstützung vom Team zu sichern. Gerade technische Teams verlieren sich bei konkreten Problemen schnell in technisch tiefe Diskussionen. Dabei kann bei einer Teamgröße von sechs bis zwölf Personen schnell viel Zeit vergehen. Hier muss der Moderator auf die Timebox, also das vereinbarte Zeitlimit, achten und alle an die getroffene Vereinbarung dazu erinnern.

Gerade bei der ersten Einführung agiler Arbeitsweisen tun sich manche schwer, die Fragen ernsthaft zu beantworten. „Weniger krank sein! Haha, war ja nur ein Scherz. Mir viel nichts Besseres ein. Das letzte Sprintziel war nur kaum zu erreichen, weil ich ausgefallen bin.“ Dem Scrum Master kann es schnell passieren, solche Aussagen abzutun oder sich sogar zu ärgern, dass die Retrospektive nicht ernst genommen wird. Dabei steckt in der Aussage vermutlich ein wichtiger Kern, den es zu ergründen gilt: Warum ist das Sprintziel nicht mehr erreichbar, wenn nur ein Teammitglied ausfällt, was sicher häufiger vorkommt? Fehlte die Manpower oder eine bestimmte Qualifikation oder Expertise, die sonst niemand im Team abdeckt? Durch gezielte Nachfragen erkennen die Teammitglieder schnell, wo die eigentliche Ursache von Problemen liebt, beispielsweise darin, dass es Experten-Silos im Team gibt. Durch den eigenen Weg zur Erkenntnis, ist die Motivation umso höher, die Kompetenzen im Team breiter zu streuen. Es hat eine ganz andere Wirkung, wenn ein Mitarbeiter selbst eine Schulung machen möchte, als dass er vom Vorgesetzen erst dazu motiviert werden muss.

Sollte zu einem Thema wirklich gar nichts aus dem Team kommen kann der Moderator oder die Moderatorin: