The Sprint Retro is a key part of any scrum team which is looking to improve its process and adapt its ways of working to continuously improve. As with any adaption the key is transparency, the the more information the team can gather throughout the sprint around impediments or challenges they’ve faced the better. Personally I like to create a retrospective board at the start of a Sprint so team members can add their thoughts to the board as the sprint evolves rather than looking back (which always favours things which happen in the last few days).
The main challenge with the Retrospective is to avoid it turning into a moaning or helpless session. From The Scrum Guide:
Scrum Masters use a wide variety of techniques to support gathering information about the sprint including anyonmous submissions, “What Went Well vs What Didn’t Go Well”, and often scenarios involving rockets or icebergs. However, it’s important to remember that the Retrospective is a working session to give the team some concrete actions on what they can do to increase either Quality or Effectiveness (or, ideally both). While having a good rant about something which went wrong or something which impeded them can be therapeutic unless an action is taken to lean from that then neither objective should be met.
This kind of adaption is not easy. It requires teams to look honestly at what’s happened and see what they could have done different, this kind of self assessment takes real courage and for the team to have a real growth mindset. It’s the delicate role of a Scrum Master to balance between criticising what the team should have done and coaching them to look for alternative strategies of what could be done in the future.
Its easy to say that a Sprint Goal failed because X in the infrastructure team. It’s much harder to reflect on what the team could have done to prevent that issue arising. It requires taking acountability and to avoid casting other people as villains.
In earlier versions of The Scrum Guide the team were required to add at least one action to the next Sprint Backlog, however it is now recommended to be properly alongside other work.
The Sprint Retrospective requires the three pillars of empirism to be effective however this time they must be focused inward, at what the team could change or could have done differently. It also requires the Scrum Values to be first and foremost in everyone’s mind. Impediments can come from within the team as often as outside it and we rely on our courage and respect to get us through those tough conversations.
Please feel free to post in the comments below of any retropectives which have worked really wel for you in the past, it would be great to read about them.