How To Have More Inclusive Retrospective Meetings
Background
A retrospective meeting is a meeting for scrum team members to collectively contribute feedback about their recently completed Sprint. A retrospective meeting is not a meeting to point fingers at everyone else; and blame them for what went wrong during the sprint. Your team is fundamently doing it wrong if they are not giving honest feedback during these meetings. You want to collect feedback on three things.
- What went well?
- What didn’t go well?
- Improvements for what didn’t go well.
The whole purpose of this feedback is for your team to be continusly learning and improving. Below is a very lightweight example of what collecting feedback could look like. Notice how Aja and Candee both said the same thing under the “What went well” column. I’ll explain why it’s important to document both of their responses.
My example
Tips to be more inclusive
- Gather everyone’s feedback. If you only gather certain people’s feedback then the remaining team members will feel like their voice is not valued.
- Don’t reject or ignore someone’s feedback. I’ve seen Engineering and Product Managers both “hear” feedback without actually documenting the feedback. This will also lead to team members feeling less valued.
- Collect duplicate feedback. Duplication can emphasize an issue’s importance if more than one person is repeating it. Maybe I should say that one more tim. Duplication can emphasize an issue’s importance if more than one person is repeating it 😃 . It also allows someone to add something extra to the feedback that wasn’t previously mentioned. Over time, you’ll be able to see a pattern if the same issue continues to pop up in your meetings.
- Mix up the order of who speaks first. Don’t initally call on the same person each time. Encourage all team members to contribute to the meeting.
- Collect honest feedback. Don’t try to only submit feedback that makes your team look good. Sometimes, honest feedback means addressing the ugly too. Hiding the ugly will only lead to these issues popping back up again in the future.
- All team members matter. Don’t treat contractors’ feedback with any less value than full-time members’ feedback.
- Think about feedback throughout the sprint so you won’t have to think about it during the meeting. If you neglect this, you’ll end up with less quality feedback or none at all. This happens because team members won’t be able to remember everything they need to speak about, possibly due to sprint fatigue, during the meeting.
- A scrum team is more than just engineers. Include other people from other departments that make up your scrum team or else your feedback will be bias in favor of one deparment and not your entire scrum team.
- Look back at the bigger picture. Documenting for the sake of documenting is pointless. You need to learn from your own patterns and behaviors. Make it a priority to review your sprint retrospectives’ notes every few days/weeks to see if you are repeating the same problems, actually applying your improvements and noticing if they are working.
In conclusion
Failure to become more inclusive during your retrospective meetings will prevent your team from becoming stronger at removing blockers that deliver value to your customers. You’ll end up being more inclusive by applying their feedback to the process that ships features to your customers.