How to manage a situation when one team member doesn't want to participate in retrospectives?

Question

Team works together for couple of months. They are somewhere between norming and performing phase. All team members are enthusiastic about their work and the product they work on. One of team members says that he doesn't benefit from retrospectives. He has been on many of them (between 30-50) in different teams and came up to a conclusion, that he prefers to do developer's related work instead.

At the same time he is collaborative - helps others, respects team norms, actively participates in other meetings, etc. He is a good engineer as well. Team wouldn't like to loose him; in other words a solution with laying him off the team is not acceptable.

Answer 1

The usual practice is to ask they to join the meeting, they don't have to do anything besides occasionally listening to the discussions - they can even sit in the corner. If they would like to jump in into a discussion, that agreement changes, and they have to participate until the end of the session. That is something you have to agree on face to face.

Answer 2

It sounds like it would be a good time to have a 'Retrospective of Retrospectives'. Start with a reminder of the purpose of having a retrospective and what the team is trying to get out of them. Review how the team has had retrospectives in the past, what went well, what can be improved etc. It may be the format of the meetings that is the problem, and others might have similar feelings if given a better chance to express them.

The only time I have seen a similar situation is where the retrospectives were always raising the same organisational problems, and as a team we were unable to improve the situation. If this is the case, unfortunately I can't help - I left the organisation!

Answer 3

You Can't Make Changes Without Embracing Change

You have boxed yourself in. The very fact that you're asking this question is in indication that there is friction between this developer and the team's chosen process, although you haven't actually defined the nature of the problem this is creating.

You're also looking to resolve this friction without requiring that the developer adapt to a team-oriented process, and are therefore willing to break the process rather than acknowledge that this team member may not fit within it. You simply cannot maintain the status quo and resolve this friction simultaneously.

You have essentially made the Scrum framework optional for this developer, but are trying to have your cake and eat it too. If you are going to allow each individual on the team to pick and choose the parts of the framework they like and are willing to follow, then you are not just inviting Scrum-Buts but essentially abandoning the rigor (and most likely the benefits) of your Scrum implementation.

It's okay to say that a given framework doesn't work for your team and your organization; there are certainly other frameworks to choose from. However, you must have some project management framework with rigorously-enforced controls in place if you don't want to invite anarchy.

Prima Donnas Aren't Agile

You have someone who isn't fitting into your team-oriented process. That leaves you with the following options:

1. Re-evaluating the format and effectiveness of your retrospectives, and then tweak the ceremony until it's providing value to everyone.
2. Providing education, incentives, and consequences to ensure that all team members participate effectively in this mandatory Scrum ceremony.
3. Ditching the Scrum process if you aren't planning to follow it anyway.

Scrum is about teamwork. Lone wolves, even if they are technical rock-stars, are toxic to agile processes.

Retrospectives are Required by the Scrum Framework

One of team members says that he doesn't benefit from retrospectives.

This team member is missing the point. Whether or not he benefits from the retrospective is irrelevant; the real issue is whether or not the team benefits from the retrospectives.

In addition, the Sprint Retrospective is a formally-defined Scrum ceremony that is essential to the inspect-and-adapt process. That means that you must hold retrospectives if you're adhering to the formal Scrum framework. Failing to hold effective Sprint Retrospectives reduces the effectiveness of the framework, and is counter to core agile principles.

Finally, you must carefully consider whether you are willing to have your process hijacked by someone who is unwilling to be a fully-functioning member of the team within a team-oriented agile framework like Scrum. If you allow this team member to dictate process to the rest of the team, or to unilaterally pick and choose the elements of the Scrum framework that he wishes to follow, then this is neither agile nor Scrum.

As the Scrum Master, if you abdicate your responsibility to referee the Scrum process in order to placate an individual, you have failed to do your job. Instead, you should ensure that the retrospectives provide value to the team, and that the team functions as a team at all times.

Answer 4

What format are you using for your retrospectives? In my experience, changing up the format can improve participation rates. If you are just using a 'wheel of change' with the expectation that team members will speak openly in front of their peers, try switching it up a bit. Create histograms for focus areas and ask team members to place stickies on how well they (personally) view performance in that focus area. Alternatively, try the "Once Upon a Retrospective" approach as outlined in StickyMinds.com. Above all, make sure you document all proposed changes and assign action items to team members, then follow up before or at the beginning of the next retrospective.

Answer 5

[Modified] As mentioned below, I misread the reactions assuming that not having actions done was the main reason for not attending. Below answer may thus be off topic, but I left it here as I feel that it might still be useful for the readers of this thread.

I think the team member has a point if he feels that the actions coming out of a retrospective are not acted upon; that's a serious problem.

Has this been investigated, are the root causes known? That would be the first thing that I would do.

If actions are insufficiently done then you have to stop the line and address that. Reasons that I see for not having actions done are:

Actions are too vague, people don't know what to do. Actions aren't visible, people tend to forget them while doing daily activities. It is unclear why the action should be done, missing the problem that it should solve. There's insufficient culture for continuous improvement.

All of these can be solved, but you need to know why there's insufficient follow up to address it.