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. Instead, we should be learning, celebrating, and improving as the project unfolds. While this is true, when we are dealing with complex work, we do not want to wait until the end of a project. Project retrospectives center on a project, often at its end as people know a lot more than they did at the beginning. There are other difficulties including bringing together people who may not typically work with one another on a daily basis. They require more time to address given the context effect–simply trying to recall out-of-context information from months prior is challenging. They may be done by one team, involve multiple teams, or include a cross-departmental group. Release retrospectives concentrate on the release of a product or service. 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. Let’s review a few types and consider the issues with most lessons-learned meeting. 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.

I wrote about agile team retrospectives in a recent article and find that the term retrospective can be used in many different ways.

Retroactive vs retrospective