If you follow Scrum (or agile) practices, the term “retrospective meeting” should be familiar to you. The Scrum Guide, defines retrospective as “an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”
Despite retrospectives being a necessity, according to the Scrum Guide, some Scrum Teams might consider skipping it or doing very short retrospectives instead in order to adhere to the guide, inevitably lacking any clear goal. However, the retrospective meeting is a very important part of the process, if you aim to have long-term processes that are stable. Also, if a team doesn’t work by Scrum, adding scheduled periodic meetings, such as retrospectives, will ensure benefits.
This meeting is where you can very easily discover potential problems with your processes at the very beginning, make a platform for honest peer feedback between your team members and focus on improvements that are most desirable within your team.
If the team doesn’t understand how it can gain these benefits from the retrospective meeting, below are a few steps a Scrum Master (or another person in charge of holding retrospectives), could take to ensure that the meeting will be effective and productive.
Schedule a time-boxed and timely retrospective
A retrospective is a kind of informal meeting and it is a given that people will want to talk about a bunch of topics that are not relevant for the final outcome. This shouldn’t be suppressed, but time-boxing will ensure that a natural tendency for focusing on more important topics, is channelled. Also, scheduling a retrospective immediately after a certain amount of work has been finished (Sprint) and right before you start with next iteration, is very important, as it emphasises what a retrospective is about, and enables the team to plan for the next iteration – especially the improvements they wish to make.
Each person in the team must have a chance to talk
It’s important having diversity in the team, but in most cases, it means that there are some very loud and some very shy people. Retrospectives where only the former group talks, are likely to end up with a partially good conclusion. If all team members are not interested in participating, the coordinator should find a way to give them an opportunity to voice their opinions, as well as ask them for their thoughts.
Speak in a positive tone
Different teams could ask themselves different questions, but eventually these questions should be possible to group into “achievements” and “wishes”. In other words, conversation on retrospective is always about improvements and never about blaming. Instead of asking “what the team didn’t manage to accomplish in the last iteration”, it’s better to discuss it in terms of “what the team would have hoped to have accomplished”.
Select improvements that are the most feasible
The ultimate outcome from the retrospective should be the next few steps the team will take in the next iteration in order to improve its processes. Some team’s “wishes” could be very popular among the team, but unfortunately, far-fetched. If the goal seems impossible to achieve by the next retrospective, try to divide it into a set of steps and take only the first steps the team can realistically accomplish.
Dedicate person(s) that will work on the next steps
If a team decides on the type of improvement they want to implement, what should also be decided on, is who is responsible for leading it. If it were to be left at everyone’s will, there is a very good chance that nobody will feel responsible enough to take the first step. Also, if it’s not possible to decide on who would be given this responsibility, it probably means that it’s not clear enough as to what has to be done.
Start the new retrospective with a throwback on the previous one
Even if the retrospective is very successful with the obvious final outcome, the team may feel like there is no benefit. The reason could be the lack of reflection to things the team decided to improve on, in the last retrospective. This way, if everything goes smooth, the team will know that the retrospective helped them stay on the right track. If not, this implies that there is a need for some sort of change in order to make the retrospective more effective.
Conclusion: Even if the team follows all of the good practices and tips written above, it doesn’t mean that the team’s retrospective will be successful. Each team has a different dynamic and different individuals, therefore the organisation of each event and meeting, should to be adjusted to the team’s needs. It’s up to the meeting coordinator (in most cases, it’ll be the Scrum Master) to find a way to engage all of the team members and use the retrospective for helping the team to inspect and improve themselves, not to be stuck at a standstill, with a lot of unrealised “wishes”.