Project Retrospectives: When looking forward makes more sense than looking backward
Recently a consultant asked me if I encourage teams to do a project postmortem or retrospective once a project is done. The goal is to review what worked well and what didn’t. The truth is, even though I think they are valuable, I don’t regularly suggest project post-mortems as part of the process.
As I prepared this post for my blog, I found that even though I use project post-mortem and project retrospective as interchangeable terms, others use them very differently. Project post-mortem are the typical project reviews that occur at the very end of a project. Project retrospectives are typically associated with Agile projects and are done after several iterations or a release. So there may be multiple project retrospectives per project.
When I think about why I don’t typically recommend project post-mortems, it’s probably because a project post-mortem tends to be viewed as a painful waste of time, rarely creating true value. When I’ve participated in post-mortems, it’s difficult to point to a process or change that came out of them that actually helps the team become more effective.
With the Getting PredictableSM mantra (Setting Teams Up For Success) reverberating in my brain, I revisited the idea looking at Project Retrospectives to see how they can be conducted to truly add value. I even wanted team members to bring a list of items they have been collecting to discuss (yes, I set the bar high).
We came up with a couple of suggestions that can make project retrospectives more constructive for all of us. These suggestions can even be applied to the original project post-mortem approach:
Change the “When”
First, change the timing of the review. Don’t do it at the end of the project.
If you’re working on a scrum project, do it at the beginning of every monthly iteration meeting. If it’s an agile project, maybe you’ll do it every other release. If you’re doing a waterfall project, then do it at every project showcase. Do it every time that you deliver software before going on to some sort of next phase.
This way the focus of the session is about “How do we get better right now”.
Change the Actual “Language”
You’re not there to ding anyone and you’re not there to be judgmental. You’re there to find out what worked and what didn’t. I suggest using different words.
Instead of working backward and asking what went right or wrong, literally start the project retrospective by not calling it a retrospective at all, but by asking, “What do we want to do differently moving forward?”
This puts everybody in a different mindset, because you’re not looking backward and talking about painful moments. Instead, you’re looking towards the future. You accept the call to action and you look at all of the steps of your process. The core concept is to connect the dots to where you want your team to be in the future.
Your Call To Action
Take this blog post and share it with members of your team. The goal here is to make sure that during your next iteration you spend ninety minutes breaking down the key areas: requirements collection, project management, staffing, testing, development practices and deployment. As you review each area, continue to ask, “What choices can we make today that will make this more successful moving forward?” See if you can come together and make a difference.
Make the retrospective a living thing that occurs on a regular basis throughout any project. Although there’s nothing wrong with talking about the past, ideas tend to flow better when you break out the bag of magic dust and focus on tomorrow.
Category: For Practitioners, Team Dynamics, Team Performance, Uncategorized