Once a scrum master shared a concern that the retrospectives have become boring and neither she nor her team members feel any value out of it. We all have faced this challenge in the past and would like to share few pointers than can be considered as good guiding principles for retrospectives and why they are the strongest tool in the agile toolbox to make any team better, and it does deliver business value.
Sharing outcomes of previous meetings
People tend to abstain if they find that nothing from previous retrospection has improved. The difference I have observed when sharing the outcomes with the team is that they do realize that few items under ‘areas of improvement; in the past has become ‘things that went well’ in the sprint. Also when discussing on thing to changes, ask team’s opinion on action plan and come to an agreement. Caution: Do not force yourself to prove everything has improved; be honest in admitting that some things have not changed.
Pat on the back
When team members do something exceptional, we should try to appreciate them in person and give them a pat on their back. The retrospectives are a good occasion to reiterate and call out those performances. Wait for your other team members to do it and if they miss, make sure you as scrum master call them out. Nothing motivates a team member than a co-member’s appreciation. Also encourage your Product Owners and Business Leaders to send formal appreciations and it works well when you have distributed teams.
Coach them to be prepared
Coach them to be prepared for the meeting. When you a see a ‘mistake in the past’ tend to repeat, gently remind the team, before it occurs. Any new issue you see impacting the team, remind them that we can discuss in retro. During meeting encourage them to speak more based on data points than being generic, focus more on things that are controllable within the team. Make sure everyone get a chance to speak.
Change the meeting pattern
The same meeting pattern sometimes makes retrospectives boring. Mapping your sprint to something from real life can add real fun and would help fresh ideas. Compare your sprint to a baseball / cricket/soccer game. Questions using game terminologies like- Did the team had enough preparations to get in to game, which half did they play well , what should they try different in next game would give different perspective to the thought process.
Press the SOS button – Escalation
While captaining your ship, if you see issues disturbing the team recurrently, do not hesitate to escalate. Environmental issues, build failures, domains not resolving dependencies etc. cause disruptions, especially if you have short sprint durations. Escalate to senior management.
Show them the trends based on Metrics
Sharing sprint metrics like team average velocity, bugs logged in the sprint; team commitment accuracy etc. during retrospection helps the team to understand the trends on how they are performing. I have seen that it has enabled them to make their own decisions in terms of how much stories they can commit to, come up with ideas to reduce defects etc.
Say Thank you!!
Ending the meeting with a Thank you, appreciating their active participation does matter a lot. It creates a feeling of being important and listened and this instills a sense of belonging. Also when they see their suggestions are put in to actions, they will actively involve in future retrospections.
