August 13, 2015
Over the last few months, I have been writing about how to improve team retrospectives. This has been mostly focused on Agile teams. Recently I’ve been asked to facilitate a “retrospective” for a traditional project.
I remembered that a few years back, I wrote about why I felt that traditional lessons learned for projects were a waste of time. My thinking on this topic is still the same – I still feel like those traditional lessons learned activities are a huge waste of time.
The genesis of my 2012 post was a negative reaction to an article posted in Projects at Work written byJohn D’Entremont, PMP and titled Learn your Lessons. This is a summary of my thoughts on the topic as I prepare to conduct a retrospective for a traditional project.
My main complaint about traditional lessons learned meetings is that they are usually focused on assigning blame rather than on learning something and applying it to improve future work.
So I am generally skeptical when someone even asks for lessons learned or post-mortem. I wrote about the importance of psychological safety and the impact of fear in this post. For now, let’s focus on getting something useful from the lessons learned meeting.
Teams that are able to avoid the blame game often wind up struggling with applying the lessons learned to future work. Gathering the lessons learned is rarely the challenge.
We often collect lots of lessons about what did not go well. We just don’t do anything useful with the information. I don’t believe that you should waste the time and effort on “gathering” if you don’t have a process for using them. Which relates to one of my favorite Agile principles.
“Simplicity – the art of maximizing work not done – is essential.”
We should not do any work that doesn’t need to be done. We should not spend the time collecting lessons learned if we don’t have a use for it or a systematic way to incorporate them, leverage them, or make them part of the team or organization’s collective knowledge.
Producing a lessons learned write-up that doesn’t have an immediate purpose is incomplete work or waste. It will be a task later for someone to retrieve, dust off, analyze, and determine a way to use this interim work product. And like other types of inventory, incomplete work that remains unconsumed gets stale and spoils.
I know that many of you are thinking, but we do have a plan for how we will use our collection of lessons learned. I’ve heard a lot of approaches to this and tried many myself, and I just don’t think that any of them are good:
I also don’t agree with the approach to tie lessons learned to the end of project lifecycle phases. If you only perform initiation or planning once per project, why bother to do a post-mortem after the phase? It’s not going to help that project. And chances are your lessons learned aren’t going to help the next project either because the next project will be different in some way. You aren’t going to implement SAP again at your company.
There is an excellent white paper on the Papercut PM which demonstrates this point very well. “This is why we can’t have nice things: A Project Risk Retrospective”, talks about the 1st and 2nd projects to build the Panama Canal.
The first unsuccessful initiative was led by experienced French construction lead Ferdinand De Lesseps. De Lesseps had the benefit of successfully completing the Suez Canal project. The second Panama Canal project was led by US General George Goethals.
Goethals had the lessons learned from the prior French-led project. The lessons learned were valuable precisely because they were from nearly the same project, not a similar one!
“De Lesseps had no idea of what awaited him in Panama. While he had previously built the Suez Canal, the geographical environment at the Egyptian work site was flat and dry with marvelous visibility.
The Panamanian rainforest was the exact opposite—much of De Lesseps’ previous work in Egypt proved irrelevant in tropical conditions. Goethals, on the other hand, had the benefit of the previous French failure.
All of the lessons of “what not to do” were littered across the Central American countryside for anyone who wanted to look. Goethals should rightly be praised for seeking this information but had this analog input to his plans been absent, his results may have been very different.”
In the Scrum Framework, there is a retrospective at the end of every sprint in Scrum. Since the sprint is only one week to 30 days long, the lessons learned are easily recalled. Plus, ideas for improvement can be immediately tested in the next sprint. Unlike phases, where different work is done by phase, an agile sprint includes analysis, design, development, and test. So the work the team does from sprint to sprint is similar and the team can really fine tune their process.
There is an Agile principle that speaks on the process.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Regular intervals don’t mean the end of the phase or the project. It means throughout.
I’ve written extensively about how to use the agile retrospective effectively including how to set the stage for an effective retrospective, what retrospective techniques to use to maximize the effectiveness of the process and 6 tips to improve your agile retrospectives. I’d love to hear from you about your experience with lessons learned and retrospectives.