BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Handling Your Team's "Rotten Apple"

Handling Your Team's "Rotten Apple"

Leia em Português

This item in japanese

Over the past few days there has been a very active discussion in the Scrum Development Yahoo Group about what to do when one person on your team is "under-performing".  In the 130+ response thread, Rotten apple in Scrum team, discussion ranged from advice for the primary question, to talk of team morale and who manages it, to the classic debate of measuring individuals, to distinguishing whether a team is really a "team", and more.

Marko Majkic initiated the discussion by describing a member of his team who he perceives as being a relative "under-performer" and asking for advice on how to approach (quote derived from the original post and a later response):

Average contribution per developer is 38 usp (user story points). One of the members makes only 19 usp - twice less than the others
...
I don't think that this guy is lazy or malicious. It looks to me like he's mind absent on work and/or has lack of concentration
...
Should I bring this to Scrum review meeting or I should talk with this guy in private? What would you do?

From this statement many topics were launched, one of which being a discussion around Marko's primary question about how to handle the underperforming individual. Many of these responses lead back to a basic suggestion that the most crucial action is to do an fresh, objective evaluation of what is really going on. Paul Hudson summarizes:

As others have said, you may need to step back here. It seems to me based on what you have said that you may have assumed the individual should be blamed for the low productivity, rather than supported in addressing any underlying issues.
...
I think I (and several others) are encouraging you do use other points of view. There’s no magic bullet. You need to find out what issues the person concerned may have and discuss them with him.
...
So the [concrete] suggestions have been:
a) Check the problem really is a problem, and is what you have assumed it to be
b) Get more information about the issues the guy may be facing
c) Raise and discuss the problem at the team or individual level

Further advice on how to act on Paul's high-level listed suggestions included things like:

  • Be careful with the words you choose to describe this individual; namely, "Rotten Apple" is probably a terrible way to refer to this situation, let alone this person!  (note that Marko clearly agreed wholeheartedly with this sentiment)
  • Mark Levison's advice to approach the situation with Beginner's Mind (as introduced by Jean Tabaka and David Hussman)
  • Various people's advice, including George Dinwiddie, to taking some time to pair program with this person
  • Advisement to remain objective in judgement, including suggestions to take queue from Linda Rising

Interestingly, further discussion revealed that Marko's concern wasn't so much about the actual output of the individual per se, but rather a fear that the rest of the team might soon react negatively to the individual, perhaps by bringing this up at a retrospective. As might be expected, many responses were quick to stress that this is a desired outcome, not one to be afraid of. As stated by Ilja Pruess:

I would actually worry much more about what *not* speaking up would do to team atmosphere.
...
So if I felt that there were bad feelings about this "underperformer" in the team, I'd see it as my responsibility as a facilitator to *encourage* team members to speak up, end to help them resolve it gracefully.

From this came also discussion around the topic of "team morale". Particularly noteworthy were responses to the question of who is "in charge [of maintaining team morale]?". Responses by Alistair Cockburn, Dan Rawsthorne, Michael Wollin, Paul Hudson, and others debate whether this is the Scrum Master's core role, project manager's, product owner's, the team itself, ceo's, other's and/or all of the above. Also, an informative reference on how to improve morale was presented in the midst of the discussion.

Also prompted from Marko's initial statement was a revival of the discussion around measuring individual performance (re: Marko's use of "points per person"), highlighted by Ron Jeffries' reminder that there should really be no such thing as "points completed per individual" if the team is really operating as a "team". Related discussion posed the idea that measuring people's performance (objectively) may not necessarily be wrong, but should be used only as one input of many to your subjective evaluation of an individual (eg. Eric Deslauriers' entry).

For more on this subject, see a recent popular InfoQ post on "performance reviews", as well as two recent blog entries by George Dinwiddie on team chemistry and judging performance, and also one by Mark Levison.

Finally, remember, as of this writing there were 130 responses in Scrum Development Yahoo Group discussion, so understand this InfoQ post is merely a light overview of some of the key items. Check out the thread yourself to get the full picture of all that was summarized here, and of course be sure to add your thoughts either there and/or here.

 

Rate this Article

Adoption
Style

BT