Last week I facilitated a retrospective of the last six months with my team. It was the first one we’ve ever done. And while I expected at least a little mud-slinging, it was actually very productive and I learned from the experience.
The only other two retrospectives I’ve ever been a part of focused only on the negative aspects of a project, so I wanted to be sure we captured more than just the negatives. In my previous experiences, there was also zero follow through after the fact. I wanted to be sure we didn’t fall into that old trap, so I did some preparation. I took a gander through Esther Derby’s retrospectives archive on her blog and came up with some great ideas.
- Capture it accurately – Sometimes I didn’t fully understand what was being said, so I took care to ask if I was paraphrasing it correctly.
- Choose a focus – We didn’t do this right off the bat, but a couple of common themes emerged so we were able to stay productive and not overwhelm ourselves.
- Get everyone in the same room – It won’t happen every time considering we have a distributed team, but kicking off the first one with everyone in the same room went a long way.
- Ask “what happened?” not “who did/didn’t do what?” – I felt this was important to do and occasionally when we deviated from this, our statements turned into “you did this” rather than “this happened and was difficult for me to deal with”.
At the end of the meeting, it was suggested that we hold a post-release retrospective immediately following the stand-up meeting after each release. In addition, a common theme in our meeting was how much manual work we have for both testing and releasing, so we chose the focus of automation for the next meeting.
I was not entirely sure how we would execute against many of the suggested changes. A common idea is always to incorporate the changes as a story into your regular work. I am fearful that they will always get prioritized lower than any of the business work if we do that and they will never get attention. One team member proposed what I think is a brilliant idea. We break the proposed changes up into doable actions vs. changes that are very much out of our control. In addition, and here’s the brilliant part, each person chooses one or two things that they relate to and take ownership of it. There was definitely some hesitation as to what ownership meant. Automating an entire regression test suite in the next month isn’t something one person could do, but one person can lead the change by choosing a tool, writing that first test (the hardest one), and getting it set up in the continuous integration build.
I learned quite a bit from this process itself and plan to incorporate the following into future retrospectives:
- Don’t wait six months
- Rotate the facilitator role – I was recording so faithfully that I never felt like I was really participating.
- Include supporting teams – This was something I specifically wanted to avoid the first time around because I wanted to be sure we were productive and had at least some sort of focus. In the future, I think it would be beneficial to have members from supporting teams provide input as we all have dependencies on each others work.
All in all, this went really smoothly and I felt like the team was really energized afterwards.