Reflection: Lessons Learned vs. Retrospective – Which one will you implement?

Throughout my career, I’ve managed several projects and one of the final project rituals which is a must do is the notion of lessons learned.  Earlier in my career, I decided that I would make lessons learned part of a weekly status reporting exercise.  I’m not a fan of doing lessons learned at the end of the project and logging it to a repository which no one will use or look.  

This week, I’ve been thinking a lot about a notion of lessons learned – Are they really valuable?  Whether you do it at the end of a project or throughout, do we get the right lessons and is it agreeable with the whole team?  Here is a typical lessons learned exercise:

• Project manager holds an hour meeting at the end of the project to discuss lessons learned
• The team discusses what went well and what needs to be improved 
• Project manager logs lessons learned in a log
• The document gets filed in a repository

If you look at the above steps – how do you know if the entire team was engaged or whether the lessons learned will be reviewed by a subsequent project team?  These exercises are typically great for extroverts like me – Love to talk and love to throw suggestions – but what about the rest of the team?  

In the Agile world, Scrum introduces a retrospective ritual which is conducted at the end of the sprint.  During retrospective, the team provides feedback on the sprint and the process.  A way that our coach has trained us is by following the below framework:

• Give sticky notes to each team
• Scrum master places the following categories on a white board:  Went Well, Went Bad, One-Time Occurrences
• When the team places the sticky on the board, they make sure their statement is unique and not a duplicate
• At the end of 10 minutes, scrum master asks the team to vote by placing a dot on the sticky.  Each person will have 3 voting dots per category
• Scrum Master discusses with team their three highest vote item per category and documents the results
• Next – Scrum master places the following categories on the board:  Start, Stop, and Continue 
• The process of writing, voting, reviewing, and documenting occurs as previous
• At the end of the retrospective, the team makes the commitment to work on the highest vote and the document gets posted to a place where it is visible to the team

Sounds simple – Tools that are used are white board, sticky notes, and markers.  I have several introverts in the group and I see them engaged throughout the process.  There are two main things that allow this process to be effective:

•  Reflection vs. Brainstorming – Each team member is empowered to write their thoughts on the categories.  Since this is a reflection exercise and not brainstorming, the fear is eliminated of talking to group on your thoughts.  It eliminates the feeling that you are being judged or getting cut-off.
• Voting – The only items that are discussed are ones that have the highest votes.  This allows the group to focus and discuss items that are most important.  This process engages all personality types and doesn’t get overshadowed by the extroverts or the one that has a lot to say at all times. 

I’m sold on the notion of retrospectives – whether I run a project via traditional waterfall or agile, in order to get “lessons learned”, the retrospective framework provides the tools and techniques to effectively get team’s thoughts on how the project or sprint is going and what practices should start, stop, or continue.