Retrospectives are one of the many powerful tools to review and improve your team’s approach to solving problems. For many project teams, they do a retrospective at the end of every 1–2 weeks. If you’re already in the habit of running a retro every week or two — Great! Keep it up! But, is it time to retro your retrospective? Are you optimizing the retro tool?
First, what are the goals of a retrospective:
A retro can easily become a catch-all for people issues. While many challenges may be the result of the wrong people in the wrong seats, a majority of issues come down to incomplete or broken steps in the process the team follows.
Accountability is hard when there’s not a process to be accountable too.
A process-focus puts attention on how we, as a team, create a winning scenario for ourselves. By using the retro to focus on the process, the team is owning the methods to be held accountable too. Not to mention, it allows people who are confused or unclear, to get clarity.
#2: Consistently used
You can do a retro at any time. Many teams I’ve worked with would jump into a retrospective when things seemed uncertain or off-kilter. However, a word of caution…
When your team is unsure of the next opportunity to address process challenges, they’ll take action at the moment a single person feel it’s most appropriate, irrespective of the rest of the team, or, in the best case, at a time when they can garner the most support from others.
The vocal majority will likely take ownership of making a change, rather than allowing all member of the team the opportunity to speak up and address their concerns; it’s less safe for everyone involved. Consistency creates an environment of accountability and sets expectations. If others are jumping the gun, bring it up during the next retro (it’s very meta!)
Even if consistency looks like once every three months, it’s better than ad-hoc. If that’s too often, let the team reflect on that during the next retro, as a group.
#3: Easy to run
Our team is remote, and for years we’ve run our retrospectives with a basic 3–5 column Google Sheet. It’s enticing to use a fancy tool to run a retrospective, but we’ve found a three column approach is more than sufficient.
- "I like..."
- "I want..."
- "I wonder..."
"I like..." points out what went well. "I want..." calls out what we'd like to improve. And "I wonder..." opens the floor for discussion around one of the previous columns or a neutral question (e.g., "Are we planning to release this in the next iterations?").
Yes, there are issues. At times fields will get overwritten by someone else or the internet is slow for someone. Regardless, whenever we bring on a new team member, they don’t need to log in or learn anything new; instead, they can dive in and participate.
If the tool is standing in the way of a higher-objective, then it’s not an effective tool.
#4: Open to everyone on the project team
I can’t encourage this enough — make sure the entire project team, regardless of roles/rank are able to participate equally. It’s like King Arthur’s round table.
The most common role kept from a retro is the Product Stakeholders. I can understand why: They often hold situational authority over the people on the project, so, it can be hard to speak openly or for them to keep directives to themselves.
I’ve been a Product Stakeholder and fostering a level of trust that allows for a true openness is hard — feeling impossible, at times. Regardless…
Don’t expect Stakeholders to have empathy for the struggles of the project team if they’re not allowed to share in the process and celebrate the successes.
Otherwise, they’re outsiders and the best they can do it sympathize. Now, that doesn’t mean a Stakeholder is free to violate the guidelines of this process.
If your Stakeholder is having trouble following the tenants of a retrospective, sit down with them, talk through the goals of the retro, and how they can help best (of which the last option is “don’t participate.”) I say again, it’s a round table — no head.
#5: Shame- and blame-free
I look forward to the day, saying be “shame- and blame-free” seems entirely out of place — but alas, it’s not today. Retrospectives require open reflection; where all team members are openly discussing the good, bad and the ugly.
It must be a safe environment for the team, or the first thing to go is honesty. It’s like solving a puzzle without knowing how many pieces you have or what the final picture is supposed to look like.
“Haven’t we already discussed and solved this?”
Maybe. But, that doesn’t mean the contributor feels it’s resolved. While this may be an honest follow-up question, I’ve found it said in response to criticisms more than compliments and successes. An alternative would be, “let’s dig a little and see if we can find a better way to address this.”
On a rare occasion, a person is bringing up an issue that is resolved, the team is following through, but they don’t like the action being taken or disagree with the decision. That’s okay. This should not give permission to passive-aggressive questions. Instead, I would discuss the concern again, identify a check-in point (example: “two retros from now”), and have a 1-on-1 with the person to make sure that there’s nothing underlying the issue that should be addressed.
“These are all the same.”
The practice of “squashing” or combining similar topics is efficient — keep doing it — but make sure each individual contributor is in agreement that their concern is being addressed.
If you find that the concerns of a few people are consistently being squashed, I would suggest holding off. It might add a few minutes to the retro, but take the few minutes over silencing a fellow team member.
“Sounds like a personal issue.”
It’s possible but unlikely. I’m a firm believer that most issues are a process problem more than a people problem. Dig for the systemic issues that lead to the issue. Often a lack of clear objectives, regular check-ins, direct (not passive) communication, and/or consistent practice lead to “personal issues.”
If all the above are in place and being followed consistently, personal issues are more easily identified by mentors/mentees and can be caught and addressed during 1-on-1s.
#6: Engaging and time-based
Engagement is key. It’s perfectly acceptable to change the format and frequency to re-engage the team. If the same person administers the retro, change it up. If the “good” column is a 😁, change it. Because the formula is basic, you can afford to have fun with it.
Retrospectives are not 60-minute accountability meetings. Celebrate of all the hard work — whatever the result.
The first 2–3 retros are likely going to run longer than subsequent ones. In the beginning, a lot may come up; this will likely subside and get shorter. At ZEAL, an all-company retro might be as short as 15- to 30-minutes.
Shorter may be a sign that the team is not fully engaged, but let that be the trend for 3–4 retros before you bring it up. Summer- and holiday-time will often make retros run short — it’s all good… for a while.
- 15–60 minutes;
- Use our Google Sheets template;
- Review each item, time box discussion to two minutes, or copy that item to column three (discussion or “I wonder…”). Unresolved discussion items rollover to the next retro;
- No more than two weeks between retros for the first three months. Then add the topic frequency to the next retro.
Our team has changed the format and frequency a few times over our history. We often relabel good/bad/discussion columns with emojis or leading language, such as “I wish…” and “I wonder…” On one occasion we asked that every item be phrased as a question, as an example: “How did we do such a great job treating each over the last retro?!” Regardless, our rules/principles have remained the same.
If you’re iterating, in your next retro, add these questions to your retro discussion (or “I wonder…”) list:
- Are we focusing enough on the process?
- Are we having a retro frequently enough?
- Are we celebrating our successes, or just focusing on our struggles?
- Are we on autopilot?
- Are we getting the value out of the retro process? If not, what should change?