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.

  • 6
    How does the rest of the team feel about the usefulness of retrospectives? If they find them useful, and they value his input, and he wants to help others, then it's not about his benefit, it's about theirs. :) One approach I've used with team members who don't see value in something that the team values is to challenge them to create their own format or process that they think would work for all involved. Commented Aug 3, 2015 at 16:43
  • 3
    Why does he say he doesn't benefit from retrospectives? He appears to have no problem with the format of the other ceremonies, so what makes retrospectives problematic? Also, I agree with @JeffLindsey's comment - what does the other team think about retrospectives? Do they also feel that they don't benefit? Perhaps there's something about your retrospective process that can be improved.
    – Thomas Owens
    Commented Aug 3, 2015 at 17:34
  • Is it because he thinks that the action items from a retrospective are never acted upon (especially the ones where the change is outside the purview of the team). I've seen this and frankly speaking wasn't able to solve it completely. Commented Aug 4, 2015 at 7:19
  • Please assume that retrospective process is not flawed. 5 team members benefit from it, only 1 doesn't. Commented Aug 4, 2015 at 14:04
  • "Please assume that retrospective process is not flawed. " The general idea of agile is everything can be improved - that doesn't necessarily mean it is flawed.
    – SpoonerNZ
    Commented Aug 5, 2015 at 9:30

5 Answers 5


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.

  • I talked to the team and aforementioned developer and we came up to similar solution as you proposed. For the time being he is present on retrospectives, but is sitting in the corner and working on his stuff. Whenever he hears something interesting, he chimes in. Also, he is ok with any changes to the process that would affect him, but he didn't speak up. Commented Aug 18, 2015 at 12:31

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!

  • This is not the case. A team member mentioned in question is not saying, that retrospective outcomes are bad. He doesn't try to undermine the process as well. All he says that he'd like to spend his time on development, not retrospective, because he delivers more value in his opinion. Also, as I wrote in the question, he is friendly, well skilled (not a Star), willing to help etc. Commented Aug 18, 2015 at 12:24
  • But I would agree that that this approach would be a good starting point to fix an inspect and adapt loop. Commented Aug 18, 2015 at 12:27

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.

  • 1
    No offense, but this is a lot of absolute advice and we have very little context. I wish he would reply with more info! :) Commented Aug 4, 2015 at 17:07
  • A thorough answer :-) I understand the Scrum Guide says that whole team should participate. I intentionally didn't tag my question with Scrum nor mentioned Scrum in question itself. Commented Aug 18, 2015 at 12:15

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.

  • 1
    I usually go for Start Stop Continue, but introduce other formats time to time (say every 3rd retro). This is a nice solution, thanks :-) Commented Aug 18, 2015 at 11:30

[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.

  • The author of the question does not state that this team member feels that the actions coming out of retrospectives are not acted upon.
    – jordix
    Commented Aug 4, 2015 at 13:05
  • My mistake, I saw this mentioned in a previous discussion and misread it as coming from Bartek Kobyłecki who posed the question. Thanks for pointing this out jordix!
    – BenLinders
    Commented Aug 4, 2015 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.