Your team has been heads down in a project, crafting the most meaningful experience ever for your clients, and you finally pop up for air. All that work was great, but how could your team have been more efficient? What are some roadblocks that you want to avoid in the future to make the process smoother?
The answer to these—and many more questions like this—lies in a retrospective.
The primary objective of a retrospective is to field honest feedback from everyone on your team. This feedback will boost your team’s performance and make your time working together even more effective.
At Digital Telepathy (DT), we run retrospectives, or retros for short, on multiple occasions throughout the course of a project. On some teams, retros are just part of our standard cycle, running them every four weeks (or sprint). On other teams, we get together for a retro after completing certain phases (e.g. moving from wireframes to design). Heck, we even run retros with our clients during (or after) onsite visits. Client involvement can be tough to schedule, but, man, does it do wonders for your relationship and project alignment moving forward.
While the cadence of retrospectives varies between accounts, we use the same flexible framework to improve communication and productivity among our team, and with our clients. This approach gives everyone an equal opportunity to contribute ideas for how to improve team performance. It also prevents issues from being swept under the rug.
Before you do anything, find a moderator. This is normally a non-project member who is able to objectively control the discussion in the room, group similar pieces of feedback together, and take notes on the fly.
Once you’ve determined a moderator, you’re ready to get started.
Step 1: WRITE
Retrospectives work best when everyone is in the same room. You’ll need a conference table, a whiteboard, and packs of Post-It notes and markers for each participant. Set a timer for 7 minutes (there’s no magic to 7…but it’s not too long, not too short), and have the team write down as many ideas as possible for the following three questions:
- What should we start doing on this project?
- What should we stop doing on this project?
- What should we continue doing on this project?
These “betterment” ideas can be anything (we’ve had things, such as, “Start hiring a barista while the client is onsite” and “Continue having group live demos”). This is a great opportunity to raise awareness about team issues, or to call-out unheralded wins by team members.
After 7 minutes is up, each participant will add their Post-Its into the columns labeled “Start,” “Stop,” and “Continue” on the whiteboard. You can probably see already how surfacing this information will help improve the performance of your team.
Step 2: RECONCILE
Now for the fun part! Let’s see what everyone wrote, and figure out where ideas overlapped.
With all of the ideas on the whiteboard, the moderator will read each one aloud, and the team discusses that specific card (this is where a 3rd-party moderator helps… sometimes discussions get heated!).
After reading a few cards, the moderator should begin grouping cards into similar themes. We’ve had a bunch of themes like “Client Experience” (more planned activities, defined daily objectives, etc.), “Work Session” (clearer agendas, increase developer involvement early),” and “Team Awareness” (maximizing our strengths, being more efficient).
After themes are determined, the team can decide who will be responsible for any immediate next steps, if there are any. Then the moderator will snap a picture, and write up the notes (we use Google Docs) after the retro ends.
But before the group breaks, there’s one more important step…
Step 3: REVIEW
The last step to using a retrospective to improve your team’s performance is to review the notes from last time.
Fire-up your previous notes, and run through each item that you previously wanted to start, stop or continue. This adds a level of accountability and ownership for everyone on the project. We add a comment to the item in Google Docs mentioning if we actually did what we were supposed to do.
In general, a good sign of progress is when you actually started the things you wanted to, and they show up on Continue the next time.
It should be noted that there’s no such thing as a perfect project retrospective. Each team is a little bit different, but the framework mentioned above will provide you with flexibility to experiment with what generates the most honest feedback and makes a lasting impact on your team’s performance.
What do you think? How have you run project retros in the past?