Cancelling retros is hurting your team
Whenever I meet with a new team, and begin to review their software development process, it is inevitable that I hear “We used to do retros, but then we stopped”.
And I hear the following reasons:
- We don’t have time.
- Things are great. We only need to retro when things go bad.
- I know that my team doesn’t have any issues.
Breaking it Down
Let’s walk through why each of these isn’t true. But first, what should a retrospective be? What is its goal?
Great Product comes from small iterations coupled with short feedback loops. Same goes for your Team! They also should be growing iteratively, using immediate feedback loops to understand themselves. The retrospective is where that process happens.
Therefore, success for a retrospective is:
- The team understands Why things are/aren’t working.
- Issues are discussed freely, successes are celebrated.
- The team is trying something new each week and reflecting if that helped them improve.
Just like the product itself, it is an integral part of how your team iterates and grows.
Breaking down the Myths
“We Don’t Have Time”
The first thing to go during a code crunch is the retrospective. And I understand that — it’s a valuable hour. But you are hurtling towards an end goal as a Team, not individual actors. When people work individually, there are many thoughts and concerns that can impact productivity “Am I taking too long?” “The build is broken again, should I be fixing it? But I have to deliver this story!”. When people are able to voice concerns with the team, this provides them feedback, allowing them to clear those thoughts or turn them into actions. For example, a teammate may be stressing they can’t make standups because they’re having trouble getting children to school, when actually the team is pleased how responsive they’ve been on Slack. No more worry!
Secondly, you do have time. But you have chosen that something else is of higher priority. By not setting aside space to discuss issues and success, you are telling the team that you only value output, not their viewpoints. Remember that you are a balanced team, and ideas come from everywhere. Retrospectives provides that space for ideas.
Third, the retrospective is the perfect format to get a pulse on what the team sees as issues — they are literally writing them on the board and prioritizing! Part of the role of any lead on the team (product, engineering, design) is to smooth the path for whatever the team needs. Knowing the issues the team is facing means you can now help them directly.
Instead of cancelling:
- Hold the retrospective directly after the release.
- Use the retrospective as a transition from heads-down into a social activity. Have it in the last hour of the week, and bring food + drinks. Putting it at the very end signals that people should wind down.
- OR Make it first thing in the morning: a coffee and pastries hour. Some people feel better knowing they have the rest of the day open (Just don’t do it on a Monday).
In true retro fashion, pitch the times to your team, see which has the most consensus (not unanimity) and try it for a couple weeks. Throw it up as a retro item to hear the teams thoughts.
“We only need them when things go bad”
I commonly see a team that has an issue (botched deploy, nasty bug) and immediately after they are summoned for a “retro”. That’s really a post-mortem couched in a nicer-sounding word. Not cool. And everyone sees right through it.
Standups and retrospectives are generally the two times a team meets. And standup is for updates, not for problem solving. If you only get together to discuss Things That Went Wrong, then you set a negative connotation for group gatherings. Now whenever you schedule a group meeting, people are thinking “Uh oh, what did we do wrong?”
Second, I’ll bet everyone on your team is critical about their effort and the high standards of their work. Given that nature, it’s easy to skip over the good things that happened, and instead focus on criticisms. A retrospective is literally meant for reflection — holding one regularly means you can point out the successes and that things aren’t always as bad as it seems.
- If a Bad Thing Did Happen: call it the right thing: a post-mortem and use a format designed to drive out those specific issues.
- Keep notes throughout the week of behaviors that you appreciated or tough obstacles that were overcome. Include those in the Happy column.
“I know my team doesn’t have any issues”.
Think back to any retro you’ve ever been a part of. Did you foresee that everyone of those items would be written? Did you already know how the team would vote?
I’ll bet you didn’t. I’m often surprised that what I hear occasionally mentioned in standup is actually the next UXGate and people are about to flip the table. Conversely, as a product manager, the team doesn’t always know that I’m battling the board or upper management. Hearing these issues gives us perspective and brings empathy. Allowing people to simply vent may prevent a larger blowup down the road, where people get bitter or start taking days off.
- Remember that the retrospective isn’t just for you. Others may have issues.
- Ensure that all voices are being heard: Ask quieter members their opinions, and make sure everyone writes on the board.
- Think back to anything you’ve heard mentioned in standup, and write that in the Watch Column.
- If it feels like the team is dancing around an issue, press on it by putting all your votes on the item.
You or your team will always have reasons to cancel Yet Another Meeting. Before you do this, reflect on your past retrospectives and the insights they’ve provided you and the team. Remember that positive shift in energy when the elephant in the room was addressed, and then tackled? You don’t want to lose that energy! So whenever the team wants to cancel, remind them of the great outcomes from the past, and keep that retro.