| title | description |
|---|---|
How to run a retrospective |
The why and how for running a retrospective |
Despite the size of a team or scope of a project there is always room for improvement. Running a retro allows the team to iterate on the existing processes and improve the way the team works. It is also a good opportunity to check in with other team members to collaboratively assess team health. In short, the retrospective helps the team identify how they can improve their processes and most efficiently achieve business goals.
A retrospective is a meeting held typically at the end of a sprint that gives the team the opportunity to reflect on what happened in the sprint and identify actions for improvement moving forward.
Generally, a retrospective is held at the end of a sprint. Holding it at the end of a sprint is suggested because the team has completed a sizeable amount of work that they can reflect on. It also allows the team to quickly implement ideas and improvements in the next sprint (that can then be followed up on and discussed in the next retro). The most important thing regarding when retros are held is to have them frequently enough to allow for iteration and continuous improvement.
Every team member (such as a PM, a designer, developers, and an analyst when necessary) is encouraged to join a retrospective. Also, it may be valuable to include other stakeholders when a notable milestone is completed. For example, after the launch of the Year In Art project it might be helpful to include an editorial team member for that retrospective. It is also important to be mindful of the meeting size so as to keep the focus of that retrospective manageable.
Facilitator A retro needs a facilitator whose role is to:
- Manage time.
- Assist the group in ordering/organizing items.
- Engage and encourage discussion (by asking questions/reviewing items).
- Take notes of action items.
Many articles, blog posts, and books suggest having a dedicated facilitator rather than having one of the team members play this role, which would help remove bias. In a small team, that may not be an option but is something for the facilitator to keep in mind. Rotating facilitators is also encouraged to increase participation and distribute sense of ownership throughout the process.
Format There are dozens of retrospective formats in Agile Retrospectives or online. The most commonly used one is called “Glad, Sad, Mad.” According to Retrospectivewiki, this format is described as follows:
Issues, changes or observations made during a sprint are listed by all participants and then categorized as either Glad, Sad or Mad. These broadly represent positive notes about the sprint/team, negative notes about the sprint/team, and “gripes” (which are often more broad than just actions of the team), respectively. Participants then vote on the issues to be discussed and the issues are then discussed from highest to lowest number of votes until all issues have been discussed or there is no time remaining.
- Everyone gather in a room or zoom call (or both). *
- Set a timer for 10 minutes to write down items to go in the Glad, Sad, or Mad columns.
- Once the timer is finished, group similar items or topics if applicable.
- Vote on items that you think should be discussed. * *
- Go through and discuss each item starting with the item with the most votes.
- Generate and assign action items that come out of the discussion.
- (Optional) Discuss remaining items that may not have received votes if there is enough time
* Make sure to review the action items from the previous retrospective to determine if they were useful. Ideally this should come up as topic items but it may be helpful to specifically call them out when you first start conducting retros.
* * If this is in person typically everyone gets 3-5 votes (represented by stickers) to assign to topics they wish to discuss.
Action Items Be sure to come up with action items that are actionable and can be performed by a team member or the whole team. An example of that might be:
- Issue or topic discussed: Sentry React Native, which is supposed to collect crashes, was causing a crash. Entire team has felt this pain point and the team decided to search for an alternative.
- Action Item: Yuki has agreed to do a spike to search for an alternative. This might be a task pulled in next sprint.
Tooling At Artsy it is typically the case that team members are distributed across different countries/time zones. In order to conduct a retrospective that accommodates everyone, it may be necessary to use web-based tools such as zoom.us and retrium.com.
- It’s really important to cultivate psychological safety and a safespace for retros. Retros are most successful when all team members are able to voice their thoughts, concerns, and ideas.
- In some cases the team may want to run a retro with a specific focus in mind. For example, the team could facilitate a retro for improving how the quality assurance process is done or managing technical debt. Another good opportunity for a retro is after the team has implemented a new stack or technology.
- These are by no means hard rules. Rather, this is meant to serve as a guideline and give some initial structure that teams can then adjust to fit their needs.
Resources: