Sometimes product development can feel a bit like this photo, slicing quickly through the waves. It’s exhilarating at first, but if you’re going in a circle it quickly becomes tiring as you deal with the same problems again and again. I recently wrote about the importance of continuous improvement for teams, which ensures that each cycle is a little better.
Retrospectives are the single most powerful practice for continuous team improvement. However, many teams fail to establish retrospectives as a practice. Let’s discuss the key elements of a retrospective, success factors, and pitfalls.
What’s a retrospective?
Retrospectives are the practice of looking back and learning from a project. In the context of a typical Agile or Scrum team, this means looking back at the past sprint, typically 2-4 weeks. The Scrum Guide defines the core of a retrospective as:
“The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved. The Scrum Team identifies the most helpful changes to improve its effectiveness.” (emphasis mine).
The good news is that retrospectives are pretty easy. However, there is a skill to getting the most out of them.
Retrospective structure
There are multiple ways to conduct a retrospective, but here’s a format that’s worked well for several of my teams. If you don’t have your own practice already, give this one a try.
Gather ideas
10-15 minutes
Pass around cue cards in two colours. Have team members write down their ideas and observations, one per card. Use one colour for things that went well, and one for things that didn’t.
Gather the cards into two piles.
Share & Discuss
15-60 minutes
Briefly shuffle the “good stuff” pile then pass it around. Ask each team member to take a few, so that everyone has a similar number of cards.
Go around the room and have each person read the cards he/she is holding. Listen for common themes or patterns suggested multiple times and for major wins. It’s useful to have a scrum master taking brief notes here, but the team lead or any team member can as well.
Discuss the key issues you heard. What can you do to ensure that similar successes continue in the future? Identify action item(s), who will execute them, and when.
Repeat for the “bad stuff” pile. In this case you will be looking for actions to correct or prevent similar problems in the future.
Confirm action items
Before wrapping up the meeting, review the action items and who has the next step.
It’s helpful to have the action items recorded somewhere, such as official meeting notes. It’s not necessary to have detailed notes of all the suggestions, although some teams like to keep a photo of the cards.
Remote retrospectives
Like many leaders, my team has been working from home during the COVID-19 pandemic. The following adaptation has worked well for us, without buying yet another software package:
- Create retrospective template document in either Google Docs, Confluence, or another tool with good multi-user editing.
- Two columns: Went well, Could go better (or Good Stuff, Bad Stuff)
- Add lots of empty bullet points (at least 2 per user) below each heading
- During the meeting, share a link to the document. Team members directly add their suggestions. The large list of bullets give space for people to edit in parallel without overlapping.
- We still read the cards, but we have one person read each column
- Discuss and follow-up as usual
If you’re working remotely you might also want to check out 4 Practices for Software Teams Working from Home During COVID for more practices that have helped my team thrive in this environment.
Make retrospectives valuable
The agenda above is better than average, but that’s just administrative. If you want retrospectives to be incredibly valuable, you’ll need to move beyond structure to focus on the content: purpose, control, thanks, and actions.
Know your purpose
The purpose of retrospectives is to deliver value to your team and to your organization.
The primary way retrospectives deliver value is to improve the processes and tools your team uses every day.
This means that you should leave each retrospective with at least one action item to change, or evaluate, a new tool or process.
Autonomy
In order to make changes, your team needs some level of autonomy. That doesn’t mean you need complete freedom, but you should be able to leave the retrospective with a commitment to spend at least a little time or money trying new things that you think will deliver value.
If you find your group lacks this autonomy, there are a couple of things to consider:
- Do you have the right group?
Sometimes a very small team may have very little power to make changes, but they are part of a modestly-sized department that can. Other times it’s very difficult to get a department to try things because you need buy-in from too many stakeholders, but easy for a single team. - Are the right people in attendance?
I’ve seen some teams prefer to hold retrospectives with only the “core team” and no manager. This allowed them a lot of freedom to talk, but it was more difficult to get buy-in to make meaningful changes. - Do you really need to ask?
Retrospectives excel at delivering incremental improvements. While bigger ideas may come up from time to time, you can still get a lot of value out of the small ones. Can you and your team simply make these small changes and see if they work? What’s the worst that will happen? What’s the best?
If none of the options above seem to work, this is a good time to chat with your manager. Hopefully she will be able to suggest a new perspective or describe other continuous improvement mechanisms that are a better fit for your organization.
Circle of control
The corollary of team autonomy is recognizing the autonomy of other teams. You generally can’t control how they work, so don’t try.
As a general rule, discussing other teams, or the way your company is structured, is not productive. Don’t berate anyone for complaining, but avoid spending time on it. One good way to tell that something is beyond your circle of control is when the only action items involve trying to convince someone not in the room to do something different.
Of course, if another team is really causing you problems, your own team lead should be taking what actions he can to improve the situation.
Be thankful
While I generally discourage retrospective topics that have no action, or are directed at other teams, I make one major exception: Kudos and thanks for good work. This could apply to anyone on the team or who the team interacts with.
It only takes a moment to read these cards and it can really lift team spirits. If you hear thanks for someone not in the room, assign someone to let them know. It can be as simple as an email or IM that says “I just wanted to let you know that in our retrospective today, the team mentioned how much we appreciated you ____ last week.” It’s a nice thing to do, and people are much more likely to help you out again when they know they are appreciated.
Focus and act
During discussion, it’s particularly important to focus on any issues or opportunities that are raised by several team members. On the other hand, it’s not necessary to dig-deep on every individual item.
Always end the retrospective by selecting a small number (typically one or two) actions and commit to implementing them immediately or over the next sprint. These should be actions that you think will have a significant positive impact with a reasonable effort level. However – don’t over think them.
In my experience the key to successful retrospectives is a willingness to try new things. Focus on incremental improvements that are within your team’s purview. Many ideas will be easy to implement or try out – don’t hesitate to give them a try and see how they work for a fixed trial period.
Final thoughts
I hope you have gained a better understanding of how to make retrospectives work for you. If you aren’t already using them, I give them a try. If you are, perhaps you’ve found a new idea or two that can help make them even better.
Use the comments section below to share your successes, and let me know what you think. Do you have some great ideas I didn’t mention above?
The forum is moderated and your first post may not appear until it has been manually approved.