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

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.