Good Retrospectives

Overview

Retrospective is one of the inspect-and-adapt opportunities provided by Scrum framework. It’s a time-boxed event for the team to analyse their way of working and identify and plan potential improvements.

Sprint retrospective is one of the most important, but probably also the least appreciated practices in the Scrum framework. Therefore, retrospectives have to be carefully taken care of because inspection and adaptation lie in the heart of agility. It’s an important mechanism that allows a team to continuously evolve and improve throughout the life of a project.

Atmosphere

Sprint retrospective is a time to think about the process and practises hence the full Scrum team has to attend it (including Product Owner and Scrum Master who facilitates the discussion).

Assuming trust and safety are in place, everyone is encouraged to be completely honest and reveal all difficult issues one has in mind. Team members are expected to present their opinions in an open, genuine, yet constructive atmosphere. It’s facilitator’s responsibility to ensure that discussion stays positive and professional, focusing on improvement of the team as a whole. It’s critical for retrospectives’ long-term success that finger-pointing, assigning blame and personal criticism is absolutely avoided.

Quantitative Assessment

Before you jump in into a hot discussion some reporting of important metrics should be done. It’s required to set a context for the discussion and objectively present how the team has performed.

There is no one-fits-all set of metrics you should be using – they very depend on the business context, stakeholders, project, etc. However, it’s the team who should come up with the metrics they want to use to monitor and improve their work.

Last but not least, please bear in mind that whatever you finally produce it shouldn’t be static and set in stone forever. People and teams get used to their own measurements therefore, it’s good to try something else after a while. Replacing your metrics not only helps you cover other perspectives and uncover different unknowns, but it also keeps stagnation from creeping in.

Apart from velocity, risk assessment and product quality assessment the metrics you can use may include:

• # stories
• # stories accepted
• % accepted
• # stories not accepted
• # stories added
• defect count
• # new test cases
• # new test cases automated
• % test cases automated

Qualitative Assessment

Retrospective, though important, is not a heavy-weight ceremony. It’s an open discussion that should include three main questions/points to address:

• What went well during the sprint?
• What went wrong?
• What can we do differently to improve our work?

All the improvement ideas identified in the brainstorming session should be noted down, but not all of them should be immediately converted into real actions for the upcoming sprint, though. It may sound disappointing for some team members, but they need to remember that delivering value, not improvement itself, is their primary goal. However, since iterations are short, over time, all the issues will be finally addressed (or replaced with new findings during next refinement).

Actionable commitments

Identification of actionable commitments is the key to successful retrospectives. Open discussion is desirable, but in the end, some well-defined actions have to be agreed on. And the word “actionable” is significant. Actionable commitments are well-understood by the team, have clear steps to completion and acceptance criteria, just like good stories.

Let’s have some fun

The way retrospective meeting should be held is not pre-defined. There are numerous techniques for conducting retrospectives and none of them is objectively better than the other.

To be honest, trying different constructions of the retrospective meeting may keep things fresh and interesting. After all, team’s engagement is critical for a retrospective to succeed. Some sample techniques can be found here: http://retrospectivewiki.org/index.php?title=Tools

Personally, I remember a retrospective where “Draw a problem” approach was suggested by the Scrum Master and it was a great success. The project was depicted as a ship where good things were like a wind blowing sails while bad things were showed as an anchor that prevents the ship (team) from sailing faster.

Potential problems

Retrospectives are critical for the team to improve, but they need to be run correctly to make it happen. The team has to see real benefits of spending time in retrospective meetings.

Some typical smells that retrospective is not effective may include:

• team members not attending retrospectives
• unengaged attendees
• no resulting actionable commitments
• finger-pointing and assigning blame
• lack of trust
• complaint sessions and no desire to improve

The most demotivating and frustrating problem, however, is the team failing to follow through on improvement actions identified during previous retrospectives. It makes the meeting waste of time with no real impact on day-to-day work. The team has to understand that commitments they make matter and have to be met.

There is no silver bullet to address the issues mentioned above, but it’s Scrum Master task to realise that retrospectives are ineffective and work towards addressing issues like these. And if the team is new to Scrum inviting an external facilitator to conduct the meeting is highly recommended.

Edit: A great source of restrospective’s fun: How to Make Your Retrospectives Fun