Get certified - Transform your world of work today

Close

5 Major Symptoms of Ineffective Retrospectives

5 October 2015

Suman Bhowmick
Pega Systems


A retrospective is one of the core events of Agile practices. A retrospective is the tool that enables the team to reflect and inspect on which aspect of the sprint they can improve. No matter how good a team is, there is always opportunity to improve. And a team's hunger for improvement is a sign of a great team. Conversely, without an effective retrospective meeting, teams can’t improve at all. It sounds logical and simple: Just find the areas of improvement and act to improve on those areas. But in reality, is it so simple?

For most teams, retrospectives are not as effective as they should be. In general, they're conducted just as any other meeting, according to Scrum guidelines but without gaining any real value from them.

Below are the five major symptoms of ineffective or dysfunctional retrospectives:


1. Team members avoid having a retrospective.

Have you seen this? Team members suggest that they all skip the retrospective because they have nothing important to discuss. Or they say they are quite busy, so ask whether you can make it just 10 to 15 minutes long? Have you heard another team member push back and say, "No! We have to attend the retrospective today"? These are great indicators that the team sees no value in the retrospective meeting.

But what breeds this aversion to the retrospective?
  • There's a problem with the way retrospectives are conducted. The team isn't engaged.
  • There is never a change in the meeting format. The meetings are monotonous and boring.
  • The team never sees its previously raised concerns addressed, thus sees that the meetings generate no value.
  • The team doesn’t understand the potential value of having retrospective.


2. Real problems are not called out.

On many occasions, you've known that there was a particular problem, but the team never raised it during the retrospective meeting.

Some of the reasons for not raising problems during the retrospective:
  • The team thinks it's a waste of time to discuss anything at that time.
  • The team member thinks, "I might look bad if I raise an issue."
  • Team members think that if they raise an issue, other members will think blame is being passed around.
  • If the points are communicated to a wider audience, the team believes it will look bad.
  • Team members fear that their manager, who would be present at the meeting, might think they're complainers.


3. The same problems come up every time.

Persistent problems are common in Scrum teams. The same areas of improvement come up again and again in different sprints. This indicates that there is a serious problem, and our retrospective is not at all effective in solving the problem.

Possible reasons:
  • The team is not trying to find the root cause but is instead trying to solve something that is only the tip of the iceberg.
  • No action items are identified. Thus the problem persists.
  • Action items are identified, but they're not owned by anyone. So no one works on them.
  • Previous action items are not revisited before starting the new retrospective, so no one bothers to work on the action items.


4. The team has no points to discuss.

Team members sometimes say that everything went well, and there's nothing they can think of that can be discussed in the retrospective. I am not talking about the team not raising a known problem, as discussed in an earlier point. This is about a team not having anything to discuss. There may be a few reasons for this:
  • The team has no time to reflect. The environment is not conducive to reflection or sharing. Ample time should be given during the meeting for the team to think about the past sprint and discuss it. In the absence of reflection, the team fails to recollect anything important.
  • The team is not aware of what can be called out in the retrospective. The team assumes that only big problems or big achievements can be discussed.
  • Due to previous experiences of ineffective retrospectives, the team doesn’t want to reflect and come up with points for improvement.


5. The retrospective is another name for the blame game.

This is one of the major reasons for ineffective retrospectives. During the meeting, people try to blame others, and the discussion revolves around who did it. The why part of a problem, which is the main purpose of a retrospective, is lost. These types of retrospectives are extremely ineffective, and they tend to reduce the future productivity of the team as well.

Potential reasons for the blame game:
  • A trust deficit exists within the team.
  • Serious personality conflicts exist within the team.
  • Subgroups within the team have splintered the group.
  • The team lacks a basic understanding of Agile principles.
This is not an exhaustive list of major symptoms, but they are the most common ones I've observed among various teams. If you are seeing any of these in your retrospectives, then you can rest assured that your team considers your retrospectives haterospectives.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (6 ratings)

Comments

Madhavi Ledalla, CSP,CSM,CSPO,REP, 10/5/2015 10:58:16 PM
Good summary of the symptoms!
Gaurav Bhardwaj, CSM, 10/10/2015 11:55:23 AM
Thanks you for sharing your views. I felt couple of similarities in my team.
Ian Jones, CSM, 10/15/2015 1:24:21 PM
Nice summary of problems.

Teams can become very good at swarming on tasks and identifying/resolving impediments during a sprint. Either of these could lead to point 4 - No points to discuss.

Then the team are missing that better performance need not come from impediments.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe