No team is perfect, but every team can steer toward more meaningful and more impactful work. A Retrospective is an occasion for your team to look back, reflect, and plan to work better, together.
Why it matters: At the end of every project sprint or deliverable, the project team involved should look back, create a timeline of the work, and reflect on specific points along the way that were either positive or negative to the outcome of the work.
Big Picture: The most important part of any retrospective is the tone. A Retrospective is an opportunity to look back with the intent to work better as a collective in the future. Looking back on the work, especially for a team that hasn’t done it before, can often devolve into blame-storming, scapegoating, or excuse-making.
How to Conduct a Process Retrospective
1. Draft the team. Identify the people who participated on the project or deliverable. Not every single person MUST attend, but ensure you have a representative selection of both skill set and hierarchy.
2. Schedule at least 90 minutes. Trust me, this will be time well spent.
3. Hold a role election. Start the meeting by electing a Facilitator and a Scribe. Ask the group to vote by writing names on Post-it notes. Remember, it’s the role of the Facilitator to move the meeting along and the role of Scribe to capture key learnings and next steps.
4. Generate major milestones. Give everyone five minutes to silently generate major milestones and deliverables from the project, such as project kickoff, brief development, resourcing, client interviews, launch, etc.
5. Put together a timeline of the work. If you’re the Facilitator, collect the major milestones/deliverables and chart them on a wall (with Post-its) or a whiteboard. Talk through the process with the team to get it right, and to identify milestones that the team might have forgotten.
6. Identify what worked well. Have the team identify moments or actions in the process that worked particularly well to advance the project or the team itself. Give everyone three to five minutes to silently reflect before sharing.
7. Identify what didn’t work. Have the team identify moments or actions in the process that slowed, obstructed, or harmed the project or the team. Give everyone three to five minutes to silently reflect before sharing.
8. Brainstorm improvements. Give everyone five minutes to silently generate suggestions for approaching the work differently. Specifically, ask the group to mold their suggestions into one of two formats: Policies or Projects.
· A Policy is a rule that the team should follow for all future projects (e.g. “All briefs should be written by a cross-functional team”).
· A Project is an initiative or action someone on the team should complete, likely before the start of the next project (e.g. “Source freelance design help in case our internal team can’t get to the work quickly enough”).
9. Let the team discuss. Ask everyone on the team to share their suggestions for Policies and Projects, and give the group five to ten minutes to reflect and react.
10. Group and rank the suggested improvements. After the team has had a chance to reflect, then it’s time to decide what Policies and Projects should be enacted moving forward. Start by asking the team to group and vote on the suggested Policies and Projects.
11. Make decisions. Let the group in the room have final say, using the following criteria:
· Projects: If someone in the room is willing to “own” the project, meaning they are willing to rally the people necessary to do the work and they are willing to be held responsible for whether or not the project is completed, then consider the Project approved.
· Policies: Because a policy is a rule that everyone on the team must follow and enforce, a policy should only be accepted if the full team consents to it. As Facilitator, take each policy one-by-one and ask the group to share any questions, reactions, and objections with the person(s) who originally suggested the policy.
Close out the meeting. If you’re the Scribe, make sure you’ve captured the Projects that have been committed to and the owner of each project. Also, make sure you’ve recorded the Policies consented to by the team. Make sure your notes are distributed to everyone involved with the work, in a place or format that’s easily accessible to all team members. As Facilitator, quickly run through the decisions made by the team and congratulate everyone on their hard work and commitment to making things better.
The Bottom Line: The only truly wrong way of running a retrospective is not to run one.
