We often gain a helpful perspective in life when we pause to look back, evaluate and learn before we move forward. We can gain valuable lessons by considering the past - what worked well, what could be done better or what should not be done, and adjusting our forward plans accordingly. This thoughtful reflection of the past is what is called:

ret·ro·spec·tive
/ˌretrəˈspektiv/

.....'retrospective' literally means looking back on or dealing with past events or situations.

Since Agile delivery is all about continuous learning and improvement, it is no wonder that retrospective is one of the most important and widely accepted facilitation techniques in this framework. The Scrum Guide lists retrospective as one of the five mandatory Scrum events.
It outlines the purpose of the retrospective to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.

Retrospectives provide the entire team to take a closer look at what they have accomplished and consider how effectively they arrived there. It is also an opportunity to share constructive feedback that can improve the team’s collective performance in the upcoming delivery cycles.

However, if done improperly, retrospectives can quickly become a boring routine with no constructive feedback emerging out of it, or in the worst case a mud-slinging exercise with the team indulging in blame games and "one-up-manship." This is often due to some common misconceptions about what these retrospective meetings are.  

I wanted to share and clarify a few common misconceptions based on my experience:

Misconception #1      
The Scrum Master is mandatory, but the Product Owner
is not.

Practically speaking, the Scrum Master is the one responsible for facilitating the meeting, but as a core member of the team, the attendance of the Product Owner is a must. We see many Product Owners who have missed the retrospective meeting assuming that it is an internal development team meeting. When they miss this meeting, they miss out on the opportunity to understand each team member’s view on the sprint, hear their specific concerns and to get a sense of the team’s collective perspective. That is valuable information, which can enable the Product Owner to set better priorities and better negotiate the Sprint goals moving forward.

Misconception #2           
What was done well? What wasn’t done well? What can be done better?

Do these questions sound familiar? These questions typically form the agenda of most retrospectives. While effective in the early stages, this standard line of thinking can quickly get repetitive and boring for the team. We encourage Scrum Masters to build on these core questions and to look for creatives ways to engage with their teams. Using the exact same approach and format to each meeting can lead to disengagement and potentially cause team members to become less motivated to seek solutions. Try playing games or have it as a team-building activity or an outing so that all feel comfortable to talk about issues and suggestions.

Some excellent ways to re-energize your team and get everyone back on track after executing a hectic iteration schedule is to hold these retrospectives in a fun and relaxed atmosphere.  So try doing it as team lunches, fun team building events or at least get some donuts when you are on the table.

Misconception #3       
The Scrum Master is responsible for the tracking and closing the action items.

The Scrum Master is just the facilitator for this meeting. Therefore, although they may offer to take notes or manage the output, they do not have any accountability for the meeting outcome. The team owns the outcomes, and the Scrum Master is only responsible for closing action items that are assigned explicitly to them.

For example, if the team feels that a different department is a bottleneck and would like the Scrum Master to remove that impediment, they can assign that task to the Scrum Master.

Misconception #4   
The retrospective will bring out the weak links in the chain.

Teams need to understand that retrospectives are not status reporting meetings; rather they are open discussions around roles, contributions, processes, perspectives, etc. and a forum to share ideas on how they can improve as a team. It is always about the team and only about the team.  When this is established early, teams avoid the pitfalls of blame games.

As a facilitator and coach, it is the responsibility of the Scrum Master to ensure that the team understands that the outcome of this meeting does not reflect on their performance review or does not instill a general judgment on their skills or capabilities.

Misconception #5  
Follow-the-Leader syndrome.

Although this cannot be really categorized as a misconception, I incorporate the “Follow-the-Leader” syndrome in this list as it is probably one of the key reasons why retrospectives lose its value to many of the team members.

It’s not uncommon for teams to defer to individuals in positions of authority. That is counter productive in retrospectives. In the case of Agile delivery we want all members of the team to have a voice towards improving outcomes. I’ve seen this play out on a sprint where  a lead developer felt that things had gone really well; some of the junior developers had feedback and ideas to share but were hesitant at the outset of the retrospective. It took some coaxing to get the junior members of the team to share but when they did, their ideas opened up new opportunities for the team to make adjustments in the next sprint that benefited everyone.

Encouraging team members to share and communicate constructively at retrospectives can help ensure people’s voices and concerns are heard.

While not an exhaustive list, I hope these 5 misconceptions help you think about your next retrospectives differently. 

If you need advice or additional support to facilitate YOUR Agile retrospectives or any aspect of the Agile delivery, we would be happy to help.

For quick references, please visit our Agile Resource Centre here.