Lessons-Learned vs Project Retrospectives

I wrote about agile team retrospectives in a recent article and find that the term retrospective can be used in many different ways. I’ve heard people ask, “Did you just change the name from lessons-learned to retrospective?” Although there are similarities, there are some key differences. Let’s review a few types and consider the issues with most lessons-learned meeting.

Release and Project Retrospectives

While agile team retrospectives  have a team focus on celebrating, learning, and improving their relationship on a regular basis, there are other types of retrospectives.

Release retrospectives concentrate on the release of a product or service. They may be done by one team, involve multiple teams, or include a cross-departmental group. They require more time to address given the context effect–simply trying to recall out-of-context information from months prior is challenging. There are other difficulties including bringing together people who may not typically work with one another on a daily basis.

Project retrospectives center on a project, often at its end as people know a lot more than they did at the beginning. While this is true, when we are dealing with complex work, we do not want to wait until the end of a project. Instead, we should be learning, celebrating, and improving as the project unfolds. This is why retrospectives that happen every few weeks will greatly improve your results rather than waiting until the end of the 12-month project.

“I see value in release and project retrospectives if you have been doing ongoing team retrospectives.”

Are lessons-learned and project retrospectives the same?

Lessons-learned and project retrospectives can be quite similar in concept, both considering a project after it is over (complete, cancelled, or shelved).

Celebrate Teams!

Are you celebrating, learning, and improving during your retrospectives?

Lessons-learned does not tend to be a ritual and celebration. They often focus on problems and blame and are looked at as “another meeting.” While this may not have been the intention of a lessons-learned event, or may not always be the case, try telling a group of people you are scheduling a lessons-learned meeting and look for the eye-rolls!

The Retrospective Prime Directive highlights the  ideas of respect and valuing diversity – they are critical to making a retrospective valuable!

The Retrospective Prime Directive:

“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.” Norm Kerth

Patrick Kua, in The Retrospective Handbook, recommends reading the Prime Directive at the start of every retrospective. I’d defer to the facilitator and the agreement the facilitator has with the group. As a facilitator, you could always reflect back on this at any point in the retrospective, or you may post it in the room on a flip chart. It may or may not be necessary in every group context. If you are unsure or want to stack the deck, consider reading it with zeal! I enjoyed Martin Fowler’s blog on Priming Prime Directive, on this topic.

When Lessons-Learned Goes Wrong

  1. When the focus is only on what went wrong.
  2. When the time ratio is way off (e.g., attempting to take an hour or two to run a session on a 12-month project). There is no chance for people to actually remember with this short amount of time.
  3. When the project is over and nothing can be changed.
  4. When the people who were there originally are gone because of the length of the project, or if no importance has been placed on attendance.
  5. When the goal is just to find people to blame.
  6. When everyone knows that no one will ever talk about this project or the lessons-learned again.
  7. When there is no way for anyone on the team to impact the issues.
  8. When there is no celebration.
  9. When people are being treated like resources instead of humans.

These issues can crop up during a retrospective, though I’d hazard that in that case it wasn’t actually a retrospective. In the lessons-learned meeting, these problems are much more endemic.

Assess Your Situation

Review what you are doing today and determine if you are closer to honoring the Retrospective Prime Directive or closer to my list of when lessons-learned events go wrong. Ask yourself (and others), what is the goal of the event? What would be a great outcome? Is the structure, the setting, and the goals for your project retrospective capable of achieving that outcome?  Looking for more information on retrospectives, check out Agile Retrospective Resources.


Subscribe to receive emails with my new posts and Agile Safari cartoons and Follow me on Twitter or Google +  to stay in touch!


Leave a Reply

Your email address will not be published. Required fields are marked *

Jake Calabrese

Jake Calabrese is a coach, trainer, and coach-consultant working to help organizations meet the promise of agile by going beyond agile practices to address culture challenges and help teams and leaders reach and maintain high performance. He has unique expertise as an Organization & Relationship Systems Certified Coach (ORSCC), a Certified Scrum Trainer (CST), Certified Enterprise Coach (CEC), and Professional Certified Coach (PCC), and as a trainer and coach for Agile Companies (helping non-software organizations use agile). Jake created the AgileSafari cartoon series to introduce humor into the more challenging issues we have to tackle. Jake uses ideas from various areas of thinking such as: Lean, professional coaching, neuroscience, psychology, facilitation, brain-based training, improvisation, agile, kanban, and scrum. Jake regularly speaks at local and national conferences including Mile High Agile, Scrum Gathering, and Agile Alliance Agile20xx conferences.


jake.calabrese@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author