A retrospective is a meeting that happens at particular milestones, where the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The aim is to:
Celebrate what they did well
Identify pain points they came across
This allows the team to work towards fixing those pain points, to get better in functioning as a team, and to build better products.
The aim of any retrospective is to learn. It is a place that is safe to be honest and voice all opinions. Remember, something that went wrong is a reflection not on the team member but on the processes the team has put together. It's the team vs the problem, not the members of the team against each other.
A replacement to communication required to fix issues that arise over the normal course of a project
An excuse to spend an hour venting (although some venting is normal, and possibly necessary)
A huge burden on time/resources
We used to use Trello/Airtable but we had a great experience last time using TeamRetro.
It is important to remember that tooling is not as important as getting the job done.
Neutral third party. The job of the facilitator is to
Ensure the discussion is not dominated by a few people
Nudge everybody involved to participate
Generally all stakeholders. Generally 4-8 people, most people involved in the day to day tasks and building of the project. Pizza Rules apply here.
All participants in the project must be present, not just representatives of the various teams.
The retrospective is only as good as the people included. One would benefit from a deeper understanding of the bumps along the road if you include people who were a part of the process in unique ways. However, including some people might not be necessary if their role was extremely limited.
A team that has a high degree of trust within each other
A relatively conflict-free environment (or one in which other efforts have been made to resolve them prior to the retrospective)
Most of the pre-work is to be done by the facilitator.
Setting up a calendar invite with a detailed process - maybe even link to this document there.
Make sure everyone involved understands the process before getting started - pay special attention to new joinees, and people who haven't been part of retrospectives before!
If people are remote, ensure that the meeting happens when everyone has access to a good internet connection. Ensure that the AV setup happens before the meeting to ensure a smooth flow.
Ensures that everyone has their own device by which to participate in the retro.
Share the link where the retro is happening into the chat (for quick access).
We have never had a useful retrospective take up less than an hour and a half.
0000: Set context for the meeting, introduce Prime Directive, walk people through structure, answer questions. Commit to maintain an open mind and open communication with your team
0005: The team will have 7 minutes to individually write down What Went Well
0013: The team will have 7 minutes to individually write down What Did Not Go Well
0020: The team will have 10 minutes to read through everything written down. Participants can read out the cards they have authored and explain/clarify the contents of their card. This is not a space for discussion, only a space to clarify intent.
The facilitator will use this time to de-duplicate the cards, and perhaps reword some to make intent clearer.
0030: The team will then vote on the cards that they all agree with/things that they would like to discuss.
General rule of thumb: Each individual gets as many votes as there are total number of people. The purpose of limiting votes is so that we can prioritize our discussion in the interest of time.
Votes are noted by adding themselves to the card (on Trello) or adding themselves to the vote column (on Airtable).
Order the votes.
0040: Read through all the cards on what went well. Give shout outs and pats on the back to all your teammates! Do not dwell too long here, but do make sure you acknowledge and celebrate all your wins - especially if there are things in this section that did not go so well in previous retros.
0050: Discuss "What Didn't Go Well". People who voted should be asked to talk about the card, and why they voted, and other people should be asked for opinions. Action items should be noted as they come up.
Here is where the facilitator is most required; they ensure that as each item is discussed:
All questions that arise (implicit or explicit) are answered
All voices participating in the retrospective are heard
Action Items are derived, stated and assigned owners
Additional opinions are given where necessary, and suggestions made, from the valuable role of a neutral third party observer.
And then, when you're done, you're done. Yay!
A project retrospective happens once every quarter, with a meeting between leads every six weeks to check-in and ensure movement on the previously agreed-on action items. If movement on action items does not happen even over a quarter, it is a red flag that something is going wrong somewhere.
After a retrospective, all the material must be digitized and made available to all participants.
Action Items are noted by the assigned owners after the retrospective, and it is expected that they take the necessary steps to carry them out.
Retrospectives are a great way to track progress over a large period of time; for individuals, teams and organisations. It can be quite useful to look at retrospectives we have been a part of before to track how far we have come since then, and what sort of (different) mistakes we are making now.