Stop Lessons Learned Meetings, Try an Agile Retrospective Instead

The Agile Retrospective

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.

Lessons Learned for Traditional Projects Are a Waste of Time

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:

• Posting it to SharePoint/on the shared drive/team Wiki/Confluence/Lotus Notes.  This doesn’t work.  Posting things in Sharepoint is the rough equivalent of printing it, boxing it up, and sending it to Iron Mountain for storage.  Hey, why not send it to the microfilm or microfiche department!  Or fax it to yourself so that you have a copy.  (See rant below for more on Sharepoint).
• Emailing your colleagues doesn’t work either.  They are busy and frankly, they don’t have time or interest in your lessons learned; they won’t even bother to open your email let alone open your elegantly formatted attachment.  Plus, their .NET development project is completely different than your failed SAP or mobile apps project.
• Sharing them with the next department or information sharing meeting doesn’t work. Yawn.  Nobody cares – see the previous point.
• “Hey, let’s start off all new projects with a review of the learnings from all the recent department projects.”  This sounds like a promising idea but, like, is this really going to happen?  Many new project teams are behind before they start and are often discouraged from planning so they can get right to the work.  How many of them are going to pause, go back and find all the lessons learned, determine what applies, and start with that?

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.

The Ignored Retrospective on the Panama Canal

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.”

Agile Retrospectives Are Different…and Better!

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.