All articles

Are You Making These Retrospective Meeting Mistakes?

March 10, 2012

Continuous improvement is at the heart of Agile. Retrospectives provide opportunities to the Teams to inspect their process, and continuously improve it. Many Teams fail to take advantage of this and thus fail to improve.

Common Retrospective mistakes are

  1. Infrequent Retrospectives
  2. Ignoring Improvement Actions
  3. Lack of Team Participation
  4. One Person Leading The Retrospective

1. Ignoring Improvement Actions

This is one of the most common Retrospective anti-patterns.

The Team goes into the Retrospective meeting and discusses the improvement ideas vigorously. It discusses the way things are working and how to turn around challenging issues. It uses many techniques to gather ideas. There is no shortage of ideas during the meeting, ideas keep flowing.

The Team might have discussed several dozen ideas during the Retrospectives. After discussing these items, the meeting ends. The Team does not select items it would take actions on during the upcoming Sprint. Neither the Scrum Master nor the Team captures the ideas the Team has discussed. Ideas are left behind in the meeting.

Consequently, the Team fails to make the Retrospective items visible during the Sprint. As the Team starts to do the work in the next Sprint, it gets bogged down in the tasks related to that Sprint Backlog. In the heat of the moment, Team members forget what they had discussed during the Retrospective as Sprint work starts to pile up. Tasks at hand consume all of their attention.

The Team doesn’t carry out the improvement ideas discussed during the previous Retrospective. This pattern keeps happening for a few Sprints. The Team fails to improve. The Team starts to ‘realize’ that the ‘Retrospectives are futile’. And they start to skip Retrospectives.

In many cases, the Teams tries to implement all the improvements that it has identified during the Retrospective. The sheer number of ideas overwhelm the Team during next Sprint, and they end up with very limited improvement.

2. Infrequent Retrospectives

Many Teams skip the Retrospective because they don’t understand the continuous improvement it brings. They confuse the Retrospective with Review meeting. They discuss improvement ideas about the process during their Review meetings. They fail to conduct an effective Review meeting by mixing the scope of the Review meeting with the Retrospective meeting. They chose to do Retrospective ‘on need basis’, which is typically at the end of a release or the project.

Conducting a big ‘review’ meeting at the end of a project is a legacy from traditional development processes. Many organizations confuse this end of project review with the Sprint Retrospective and decide to hold ‘retrospective’ meeting only at the end of a major release or project..

3. Lack of Team Participation

It is a common misconception that all Team members are not needed during the Retrospective. Especially, Product Owner participation is not considered very useful by many Teams. Rather at times, the Product Owner is actively discouraged to attend this meeting.

The Product Owner is an essential part of the Scrum Team. Conducting the Retrospective without her participation limits the effectiveness of the Retrospectives. Without Product Owner’s participation, it’s rather difficult to discuss improvements in the Sprint Planning, Product Backlog grooming, the Product Backlog item clarification and the Sprint Review. Product Owner participation is crucial while the Team is identifying improvement areas and coming up with improvement suggestions.

4. One Person Leading the Retrospective

In many instance, it’s hard for the Scrum Masters to hold back when they notice things which should be discussed by the Team during the Retrospective and issues which need addressing. Many Scrum Masters feel compelled to do all the Retrospective work by themselves.

Instead of working with the Team, coaching and guiding the Team to bring those ideas up, Scrum Masters do all of this work on their own. They identify the things which are working well, and how certain things should be improved. Then they ‘share’ all these ideas with the Team during the Retrospective, at once. The Retrospective meeting in this case becomes a lecture from the Scrum Master to the Team.

In the next article, I’ll point out some ideas to tackle these Retrospective mistakes.

Learn more about Scrum, Retrospective and other Scrum events in one of Scrum Master Certification Courses.

© Faisal Mahmood

All articles