Agile Retrospectives: Do they add any business value?
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.