Set the stage, Gather data, Generate insights, Decide what to do, Close the retrospective. These are the five steps that will help us make the most of our retrospective meetings.
Continuous improvement is one of the core values of agile project management and, to that end, retrospectives represent a moment of inspection and adaptation for our processes and teams. Nevertheless, we should not assume that retrospectives are meetings that can only be conducted within an agile environment.
Even if you're working in projects with more traditional management, you should set aside a moment, from time to time, to sit down with your team and reflect on how things are being carried out.
Now that we know that a retrospective will help us pursue continuous improvement, how do we carry it out?
The goal is to analyse how the latest iteration went, how we operated, what problems we faced, which aspects worked well and which did not. And with all this, determine where we want to get to, produce specific actions that each team member can carry out during the next iteration to solve the problems we found, improve the way of working and achieve the stated objective.
To this end, we can simplify the meeting by raising these questions in the following order:
- How did the previous sprint go?
- What problems did we face?
- What did we do well?
- What can we improve?
- What are we going to do to achieve that?
Someone from the team will lead the retrospective meeting by presenting these questions. The rest of the team members will answer and debate each of the aspects. The ultimate goal is to determine the actions that each team member can perform during the following sprint to achieve improvement.
- Not everyone speaks up. There are always team members with better communication skills or with stronger personalities who can monopolise the meaning while the rest barely speak.
- Repetitive meetings. The same results are repeated, retrospective after retrospective.
- Feeling of waste of time. Some team members can feel like they are wasting time, because the issues they think are important are not discussed or delved into.
- Avoidance of contentious issues. There may be sensitive issues that are not discussed because people are afraid or don't know how to present or approach them.
- Uncomfortable meetings. There may be moments of stress during the development of our projects, and this can translate to the retrospective meeting, making it uncomfortable or leaving us demotivated by the end of it.
Esther Derby and Diana Larsen, authors of ‘Agile Retrospectives (Making good teams great)’, suggest organising our retrospectives according to a predetermined structure that splits our meeting into five steps:
- Set the stage: The goal of this first stage is to break the ice or ‘set the stage’, as the name indicates. We ask questions or choose activities aimed at determining the mood of those in attendance, to get everyone motivated to participate or start guiding the retrospective towards our stated objective. For this step, 3 for 1 (Opening) may be a good option.
- Gather data: Once we have broken the ice and are ready to get down to business, the first thing to do is gather information about our latest iteration. The goal is to find out what happened during the latest iteration, what went well or helped us achieve our objectives, and what went poorly or made us stumble.
- Generate insights: Keeping in mind the result of the previous step, we now intend to generate expectations in regard to the next iteration, determining which aspects we want to avoid, which risks we are willing to take, which new objectives we want to set for ourselves... For the previous step and for this one, we can select the ‘sailing boat and the promised land’ activity. For step 2, we do the sailing boat section exactly as explained in the example linked. For step 2, we do the promised land by drawing an island surrounded by rocks, where the island represents our future objectives and the rocks stand for the risks or obstacles we may find to achieve them.
- Decide what to do: Once we are clear on the objectives and obstacles that stand in our way of achieving them according to step 3, we determine the actions that the team can perform to achieve the objectives or mitigate the risks. To this end, we can use the ‘open actions list’ activity. The actions established should be specific actions that can be performed by someone at a specific date. At this stage, we can also set rules that all team members must comply with to ensure the team's proper functioning. These team rules should be always present and taken into account at each retrospective.
- Close the retrospective: This would be the last step, with which we conclude the retrospective. The goal, apart from how the retrospective went, is for the team to come out more motivated and energised to face the next sprint. It can also be used to evaluate the retrospective. Some of the activities we can carry out here are ‘Plus & Delta’ or ‘Appreciations’.
Additionally, our retrospective can be complemented with another number of recommendations or actions (some of which have already been mentioned):
- The retrospective leader: Each retrospective should have a leader to conduct and guide that meeting. In principle, the leader should not contribute his or her opinions in the retrospective and merely observe, guide, and thank the participation of each person in attendance. This person should be a keen observer, capable of anticipating the tone of the meeting or whether the discussion is including the issues that should be dealt with, posing the appropriate questions and suggestions, without influencing the responses of other participants. Usually, the Scrum Master, team leader or similar is the one who leads this meeting. However, since he or she should not participate, this position should rotate between the team members.
- Presentation of the retrospective: The leader should present the retrospective at the start of the meeting, indicating how it is going to be organised and what will be done with the results obtained.
- Timeboxes: It is recommended that the meeting be organised with timeboxes, in order to set a limit for each section or aspect we want to discuss without losing track of time.
- Team rules or regulations: All teams should have their own team rules that must be present for each retrospective, to see if they are actually being fulfilled or even implemented in the meeting itself. For example: ‘respect the speaking time of each team member’, ‘listen to others when they are speaking’, ‘do not bring mobile phones to the meetings’, etc.
- Actions of the previous retrospective: Each retrospective produces a series of actions that should be carried out during the next iteration; therefore, one of the first things we should do in our retrospective is to check the level of fulfillment of the actions of the previous retrospective.
After implementing this system and these recommendations, we observe the following:
- Equal participation: We are able to get everyone to participate equally – bringing the shyest participants out of their shells and baiting back those who tend to monopolise the meetings.
- Focus: thanks to this structure, we obtain sorted, organised and grouped information, and we were able to focus on the problems we face and on the actions we can carry out to solve them.
- Productive meeting: The objective is to produce specific actions that a person can carry out at a specific moment, so we always have something to 'take home'.
- Use of time: Because it is a meeting structured with timeboxes, we achieve a better use of time, so that no one goes away with the feeling that the meeting is a waste of time.
- Informal meeting: By using activities, we create a more entertaining, lighter meeting, reducing the tension even if the most recent iteration has been complicated.
- Retrospective of the retrospective itself: We can take advantage of the closing of the retrospective to carry out an activity on how the meeting itself went, to evaluate it and see how it can be improved.
With projects in which I have worked recently, and the ones in which I am working now, whether they involve teams of nine or teams of three members, we use this method to conduct our retrospectives and the results are always very positive. Of course, always with the client.
In my case, because they are Scrum projects, always with the Product Owner, in order to focus on specific tasks, sprint to sprint, which are carried out and evaluated in each retrospective, changing things for the better or testing other alternatives in the event that an action carried out hasn't worked.
As you had the chance to see, the explanation of each of the steps references a web site with activities for the retrospectives. It is called Retromat and it's a website that randomly selects an activity for each of the steps we explained.
Later, if you need to, you can change the activity selected for any of the steps, by browsing from left to right. Each of the activities is identified with an ‘id’ number; this way, a unique url is generated for your retrospective, which you can share with anyone you want.
Therefore, carrying out the retrospectives this way can imply an additional effort of organisation and preparation, but the results obtained will be much better than if we merely ask the standard questions.