Retrospectives can be immensely valuable. At face value they help you solve problems in the way your team works and shortcomings in the infrastructure in which you do that work. They give each member of your team a chance to reflect on how they can improve their own work. They also give everyone a chance to voice their frustrations in a forum where they feel like they’ll be heard and acted upon.
But if you’re doing them every week, every month, or even every quarter, they can get a little repetitive. You find yourself following the same thought processes every time and coming up with the same insights. People get bored. People come up with the same issues, same actions, and never really make progress. Here are six new styles of retrospective you can try with your team to change it up, find new ideas, and find new opportunities for improvement.
1. Good-Bad-Change Stop-Start-Change 👍 👎 ♻️
Whatever you call it, this is the form of retrospective that you’re probably most familiar with. This style gives people an opportunity to celebrate what they liked about the last sprint, to vent about the things they didn’t, and to introduce experiments based on things they’ve learned recently.
How it works
Like all retros, this one starts with a reading of the Retrospective Prime Directive. Like so much of Agile development, retrospectives require an environment where everyone feels psychological safety — that is, they don’t feel like there are impediments or repercussions for speaking their minds. Of course, if no one feels that, a few words aren’t going to help. Don’t just say the words, take whatever actions necessary to make everyone feel safe during the retrospective.
Next remind people of the facts of the sprint — what work was done? What notable events occurred? Try to avoid manipulating the results too much, but
Explain the categories to everyone:
Good — What did you like about the last sprint? What went well? Let us celebrate our accomplishments and ensure our good behaviors continue into the next sprint.
Bad — What didn’t you like? What happened that we should try to prevent? What didn’t happen that should have?
Change — Forget about judging the past here. Is there something you’d like to try out next sprint? Using pull requests? TDD? This is your time to consider experiments to try.
Give each participant post-its and and a pen, and have them write a good, bad, or change item on each post-it note. Let them do this for 5–10 minutes, adding as many as they can think of.
Once people start wrap up their brainstorm, have them introduce their notes and put them on the wall. I like to post all the Goods first, then the Bads, then the Changes. Don’t let the introduction for each note last more than 30 seconds — this isn’t time for discussion, just clarity around the note.
(optional) If there are extremely similar notes, you can cluster them. But be careful of over-clustering. You might hide real, specific, actionable problems (e.g., subject-matter experts are unavailable) in an overly-generic bubble (e.g. pull requests take too long).
Vote on notes for further discussion (I like to give each participant three votes).
Discuss each of the top voted items, with the goal of finding actions that can be taken to remedy them.
Find an owner for each action, and Be The Change You Seek!
2. 4 L’s — Loved, Loathed, Learned, Lacked
Where the Change element before focused on new ideas, 4Ls makes sure we really focus on the past — problems we can fix, and lessons we can share with the group.
How it works
This one is pretty similar to Good, Bad, Change, but with different categories.
Loved — What did you love about the last sprint? What went well? Let us celebrate our accomplishments and ensure our good behaviors continue into the next sprint.
Loathed — What did you loathe? What happened that we should try to prevent?
Learned — What did you learn this sprint? What mistakes did you make that you know how to avoid? What eureka moments did you have?
Lacked — What was missing from the sprint? Did need more time for something?
3. Six Thinking Hats
Invented by Edward de Bono in 1985, the Six Thinking Hats were introduced to me by a friend at Atlassian. Each hat is a way of thinking about the sprint in order to create as many new ideas as possible.
How it works
You could handle this like Good, Bad, Change, with private brainstorming on post-its, but it helps to use each hat in order. When I do this, I like to brainstorm collaboratively, but it requires extra trust within the team to speak their thoughts in the open.
White hat — What facts and information do we have about the sprint?
This is where everyone states, without judgement, what happened during the sprint. What work did you do? What was your Sprint Goal? Did you complete it? Who did you pair with and what did you learn from it?
Red hat — How did you feel about these facts?
Did pairing make you happy? Frustrated? Did you feel sad about missing the Sprint Goal, or happy that the team adapted to changing circumstances? The feelings here are shared without judgement, and limited to 30 seconds.
Yellow hat — What were the positives?
What was good about the things that happened? We’ve identified good feelings, and now we look at what might have caused them in a bit more detail.
Black hat — What was wrong with this?
Identify negative points and judge the situation. We’ve identified bad feelings, and now we look at what might have caused those bad feelings in a bit more detail.
Green hat — What other ways can we think about this?
You’ve just spent a lot of time talking about what happened, what was good, and what was bad. Now is the time for ideas. How can we fix this? What needs to change? What experiments should we try?
Blue hat — Management
The blue hat is for organizing the thoughts you’ve had. When you use it at the end, it’s for summarizing the main points. Try to boil down themes so far, and actions that will be taken as a result. Repeat these to the team and ask them if you’ve missed anything or misinterpreted anything. Make sure that everyone is in agreement about what’s wrong and what to do about it.
4. Improvement Auction
An Improvement Auction solves a different problem than other kinds of retrospectives. You ever have the problem where every retrospective you find the same problems, and same actions, but somehow they fall off the radar during the next Sprint? There isn’t a clear owner and the problem is so “old” that it feels hopeless trying to fix it. An Improvement Auction does little to give you insight into the problems, but focuses on ensuring the actions that come out are given the priority they need to be finished.
How it works
Before an Improvement Auction, the stakeholders agree on the problem or problems that are in-scope for solving, and an amount of time they are willing to donate to the auction. For example, 3 team-days.
At the start of the auction, you give everyone the setting — the well-known problem(s) and the many failures that have happened so far.
Everyone is given 15 minutes to come up with a proposal: “We commit to solving (problem) within (timebox) team-days by (solution, in detail).”
You then break into groups to discuss the proposals and work out the details, to ensure these solutions have at least a decent chance of working, and the timeboxes are reasonable.
At the end, everyone votes on ideas based on expected impact — whether they solve the problem well and whether the timebox is large enough to actually succeed. Votes are tallied and the donated time is doled out by votes and feasibility (e.g. if the highest voted item takes 1 team-day, the second takes 3 team-days, and the third takes 2 team-days, the first and third will be funded).
The owners of these proposals now have a mandate to prioritize the work to solve the problem.
This one is more of a Futurespective that an old Development Manager taught me. The idea is to try to predict, if the project fails, why would it have failed?
The best time to do it is not at the end of a sprint or project, but somewhere in the middle. You need to have progressed far enough into the project that the team is currently living in the project (at kickoff it’s too early for them to have good insight). And there of course has to be enough time left in the project to make course corrections.
How it works
Explain the goal of a pre-mortem. Imagine we’re at the end of the sprint/project and it has failed. We want to predict why it failed.
First, get everyone write their own timeline of what has happened so far, as well as what needs to happen before the project is finished — just major events. If your project has a tentative deadline, it’s good to be explicit about when each event occurs on the calendar.
Then get everyone to take a turn combining the events from their timeline onto one on the whiteboard. As each event is added, the team should give feedback on the timing of that event and adjust the timing of the rest of the timeline based on this new information (e.g. if the feature can’t be dogfooded until the UI is complete, and we expect to need four weeks of dogfooding, we might need to move the UI work forward).
Once you have a fully combined roadmap, get everyone to brainstorm reasons why the project has failed. Did some milestone not get completed in time? Did some requirement fall through and cause the project to start from scratch? Did someone have a baby?
Share your failure reasons with the group and vote on them.
Determine actions and owners of those actions to prevent these failures from occurring.
Hopefully at least one of these retro ideas was new to you. If you give one a try, definitely let me know how it goes!