Retrospectives – or better known to a lot of people as Lessons Learned, are an important part of any project team, engineering or non-engineering.  I like the term retrospective better from my days when I first learned about Agile many years ago.  Lessons Learned has always made me feel like I am in school being told why I am in trouble.  The key concept of a retrospective is to continuously improve the team.

What is a Retrospective?

Any form of a retrospective is a forum for a team to reflect on a certain amount of the project that has already passed.  This should be held in a trusting environment with a facilitator who may or may not be part of the team.  In a hostile team environment the facilitator should be a non-team member.  The retrospective is team driven and the team should decide the best way to hold one to be most successful.

Everyone on the team participates in an open forum by discussing the following questions:

  1. What worked well for us?
  2. What did not work well for us?
  3. What actions can we take to improve our process going forward?

Why wait until the end of a project to hold a Retrospective?

The traditional lessons learned happens at the end of the project so it is a time for the team to reflect on the entire project and discuss what could be done better on the next project.  As part of an iterative environment; a retrospective is typically held at the end of a sprint for the team to have a chance to reflect on the last sprint and how to make the next sprint better.  A sprint is typically 2 to 3 weeks.

For those unfamiliar with sprints/iterations you may be thinking that seems very frequent.  The idea is to fix the items on the team before they become blockers and also to recognize what is working so those items can continue.  This allows the team to continuously improve.    

I have been working in some form of an iterative development environment for over 10 years now and cringe any time I hear about a feedback session being held at the end of the project.  If everyone was honest with themselves they know they knew of issues during the project and couldn’t figure out how to get them solved no matter who they escalated to. I am also sure that those issues were the same issues for multiple team members. This has happened to me, and I am sure it has happened to most of you. Then when you reflect at the end you need to “apply” your learnings to your next project.  What if your team is different? What if it was a special project and you never have one like that again? There is no hard fast rule that says we can only reflect at the end.

Think about that same project you were on and what would have happened if your team gathered every couple of weeks.  You’d have a forum to voice your issues, someone would have owned the issue, and you could have seen that perhaps it was an issue half the team was having as well.  If it was fixed sooner how would that have affected the outcome of your project?  Would you have delivered on time? Would the quality have been better?

These practices can be applied to any environment as well even environments outside of engineering.  Any forum where a team is together must work together to produce something on a set date could benefit from a frequent retrospective so they can continuously improve.

Retrospective Best Practices

While at an Agile conference I sat in on a session for holding retrospectives. At the time I was on a team that was having trust issues and no one was comfortable speaking up.  This session helped me learn different ways to hold one of these sessions and I often revert back to the material when I am on a team struggling. 

Here are some general tips for what I have found to be successful team retrospectives:

  • There should be 1 person running the retrospective.  A lot of times this is a PM, TDM, Scrum Master or team lead but it can also be an impartial person who is brought in from another team to help facilitate.  They key thing is, this person is the facilitator so they do not need to be a team member.
  • Review the last session’s items that were supposed to be worked on during the sprint from the last retrospective.
  • Gather the new information from the team.  This can be done verbally by going around the room/on the phone or it can be done with sticky notes and everyone writing things down.  How this is done depends on the team.  The key is that the team can choose what makes them comfortable but you still need to answer the 3 questions referenced earlier.
  • If verbally going around the room is used, then people should plus 1 any item that they agree with.   If the sticky notes are used, then the facilitator will gather those and group them into like items.
  • I believe it is very important to point out the positive as well as the negative.  Everyone knows the negative, but this is a great time to give a shout out to a team member who may have stayed late to help you or looked into code for you.  The positives help to build up the team moral and trust on the team especially when you have a lot of negatives to work through.
  • The facilitator will help to identify the highest priority items and assign items out to be worked on and fixed during the next sprint.  Not all items can or will be fixed. This is where the plus one is important.  You will be able to see if the issues are team issues verses an issue for a single person.

Continuous Reflection equals Continuous Improvement

Continuous improvement should be a word engrained in your vocabulary.  As a person I want to continuously improve to be better.  As a Business Analyst on a project team I want to continuously improve so we can deliver faster, better quality with fewer issues.  As a manager I want to help my team when they have issues so I can help us all grow and continuously improve on our craft.  Whoever you are, and whatever you do, you should constantly want to improve.  That is what a retrospective is for; the teams chance to continuously improve to become a better team to deliver a better quality product.