Retrospectives are an integral part of the “inspect and adapt” process. One of the principles of the Agile Manifesto is:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The goal of a retrospective is to review the team's process and discuss whether it needs to be improved. It's about actions and outcomes, not an airing of grievances.
Although a good team will always be looking for improvement opportunities, the team should set aside a brief, dedicated period at the end of each project (or each sprint in a longer project) to deliberately reflect on how they are doing and to find ways to improve.
During a retro, the team should feel empowered to shape their process and free to speak about where it failed and how to improve.
Everyone who contributed to the work. At a minimum, that includes the engineers, the product owner, and the designers.
Typically, managers are not invited to retros, because they can also have an unintentionally suppressive effect on open and honest dialogue.
A good rule of thumb is 30 minutes for every week of work since the last retro. We usually aim for a 1-hour retro every 2 weeks. It's okay if you finish early, but in my experience you'll use the time.
Ideally a neutral third party will act as facilitator. This frees all the team members to participate, and avoids bias. A manager should never run the meeting. This discussion should be led by team members.
There are many ways to run a retro, but the most common is to go around the room and ask every team member to answer a set of questions.
During the meeting, the facilitator will:
- Record everyone's answers (this may be handled by a dedicated notetaker)
- Keep the discussion productive and make sure the conversation isn't being dominated by a few people
- Help the team come up with a list of action items and determine who they should be assigned to
When the meeting is over, the facilitator will add the notes to the retro document and share it with the team.
It's very common to limit a retro to two questions:
- What went well?
- What needs improvement?
These naturally lead to a third category: Action Items.
Another set of questions that some teams prefer is start-stop-continue:
- What should we start doing?
- What should we stop doing?
- What should we continue doing?
If the goal of a retro is to learn how process can be improved, then the output of a retro is to share what you learned with the rest of the company.
After the meeting, the facilitator will:
- Create a retro document from the Retrospective Template
- Add the notes from the retro meeting to the retro document
- Save the document to a project-specific retrospectives document folder
- Share the document to with the company by email
- As part of the email, write a TL;DR with the top 2 or 3 take-aways for people who don't have time to read the whole document
- If there are any action items, send an email reminder or create Trello cards for the people assigned
If you've been asked to facilitate a retro, here are some suggestions:
- Double-check the project lead has already scheduled the meeting, booked the room, and invited everyone (make sure they didn't forget product and design!)
- Arrive a few minutes early, if possible. Make sure the room is dialed into the video call for remote participants, and write the questions on the whiteboard
- Facilitate the discussion, don't take it over. Ideally, you'll have to do very little, but you may find some groups need some prompting to get the ball rolling, while other groups need to be kept from drifting off-topic.
- Keep the conversation focused on process. If one team member is complaining about something another team member did, try repeating the problem back to them but replace names with roles: "I hear you saying that Engineering needs to be more responsive to questions from Design, is that right?" By reframing the problem this way, you help the group remember that they're here to address problems with the process, not assign blame or point fingers.
- Watch out for team members who dominate the conversation. If they talk over someone else, don't be shy about jumping in and saying "Robert, I don't think Alice was done talking." Or if they're doing all the talking, you redirect to a quieter teammate by saying something like "Thanks Sally, but we need to keep the conversation moving. Douglas, what do you think needs to be improved?"
If you're concerned this retro might be particularly contentious, consider spending a few minutes at the start of the meeting by establishing some ground rules:
- Remember the point of a retro is to improve our process, not assign blame. Don't make it personal, don't take it personally.
- Embrace a positive spirit of continuous improvement
- Share whatever you think will help the team improve.
- Listen with an open mind, and remember that everyone's experience is valid (even those you don't share).
- Set the boundary of your discussion – is it the whole project? the last sprint? the last quarter? Be clear how far back you're going to go.
- Retrospective Template document on Google Drive
- Retrospective Playbook from Atlassian
- 5 Tips for an Effective and Lively Retrospective