Every single project gives you the opportunity to learn. From the benefit of hindsight, you can implement ways to improve your processes for the benefit of your *next* projects by openly sharing as a team what worked, what didn’t work, and what you wish you would have known to have done things differently.
Retrospectives are critical to the growth of a team, to the growth of a company, and unfortunately – aren’t as common as they should be.
Here’s how to make the most out of this learning experience.
Set the tone
It is critical that the team is aware from the initial invitation to the retrospective meeting that the purpose of the retrospective is not a blame game. The purpose is not to point fingers at any particular person or group of people. Trying to figure out who is responsible for what went wrong with a project will inevitably lead to that individual becoming defensive, and shutting down all potential constructive conversation that could otherwise occur if they were feeling comfortable openly sharing their perspective. It isn´t worth it. Trust is critical in this exercise, and taking blame off of the table helps to build it. Norm Kerth, a highly respected software consultant and author wrote the book Project Retrospectives: A Handbook for Team Reviews which includes the “Prime Directive” which is valuable to share with team members at the beginning of the the retrospective:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
At the end of a project everyone knows more than they did when they started, and we wish we could start over using what we learned. Kerth states that this is wisdom to be celebrated, not judgment used to embarrass. Build a culture of trust. Take blame off the table, and get to the learning that comes from a successful retrospective meeting.
Require pre-work
Have the whole team come to the meeting prepared. They will each have different perspectives based on their role in the project and what they share can impact future projects. The danger in waiting until everyone shows up in a conference room ready to “brainstorm” is that important pieces may be missed as conversations flow in various directions. Have the team come prepared with answers to these questions and/or ask them to send responses to the person running the meeting ahead of time. Keep it simple:
- What worked?
- What didn’t work?
- What do you wish you knew at the beginning of the project you know now?
- What should we do differently next time?
If you feel it necessary to give the option for some anonymous feedback you can set up an online review questionnaire to gather this feedback prior to the meeting. The person running the meeting will need to determine what/if any anonymous feedback should be brought into the live meeting (provided it follows the tone of a blameless retrospective).
Start with the positive
It is natural in these meetings (especially if a project wasn’t successful) to immediately want to jump right into what didn’t go well and what the team could do differently for future projects. Most participants come prepared with a longer list of what they would have done differently than what they did right. Start on the positive. Beginning with what went well not only sets the meeting off on a positive tone, it praises the team for work that was really well done and acknowledges the pieces of excellence that should be carried over for future projects. Even projects that don’t hit their overall goals can have pockets of excellence that are worth sharing. And if you had a project that went swimmingly from start to stop? That’s worth the whole team (and other teams) knowing.
Keep it simple
A retrospective need not be and shouldn´t be complicated. The pre-work questions above are the meat of the meeting. Below is a sample, simple agenda for an effective retrospective.
- Opening – Repeat the Norm Kerth prime directive above to the whole team. Reiterate that the goal is about learning from this project to impact future projects and NOT about blame. Trust, open communication and respect is required for this to run effectively.
- What worked?
- What didn’t work?
- What should we do differently next time?
The question in the pre-work above regarding what the team wishes they knew at the beginning of the project that they now know will most likely come up during the portion of the conversation on what didn’t work. If not, it is worth asking this specifically to the team.E
Keep it focused
A retrospective is only as effective as the moderator who is running it. The moderator is responsible for making sure conversations are on topic, the meeting is on time, and the tone of the meeting is constructive. A top priority of the moderator is to ensure that everyone´s voices are heard. The pre-work helps. Before going deeply into any one topic the moderator should ensure all topics are on the table and captured (note taker needed, and white boards are effective in managing the discussion live). One way to do this is to have each team member say one comment, followed by another team member, etc. Once all topics are captured the team can spend the most time discussing those topics that surfaced from the most people.
Leave with action items
The whole purpose of the retrospective is to learn from what worked and what didn´t on a project so that it can improve future projects. Leave with a list of action items, along with who is responsible for these items and the timeframe expected.
DON´T WAIT FOR AN OFFICIAL POST-MORTEM!
While a well-run retrospective is an effective way for the team to uncover processes that worked and/or didn’t work to help impact future projects, the best teams will include a more agile approach to their development process that allows them to adapt and impact a product that is CURRENTLY in development . Why wait until a product launches to have these meetings? An easy way to start is by introducing a simple process into your regularly scheduled team meetings:
- What do we need to START doing on this project?
- What do we need to STOP doing?
- What do we need to CONTINUE doing?
The best teams learn from their successes, their mistakes, and from each other. Retrospectives help. We can as well. Reach out if you would like to discuss how we can work with your teams to learn from the successes and failures of previous product launches to positively impact your next one.