Handling Your Team's "Rotten Apple"

Posted by Mike Bria on Jan 08, 2009

Sections

Process & Practices

Topics

Agile ,

Collaboration ,

Leadership ,

Teamwork

Tags

Onboarding New People ,

Self-organizing Team ,

Culture Change ,

Retrospectives ,

Coaching and Mentoring ,

Diversity in Teams ,

Pair Programming ,

Productivity

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.

 

1. Back to top

   "Individuals and interactions", remember?

   by Ronald Miura

   Agile isn't about turning people into coding machines. We must always be aware that we are talking about human beings.
   
   At first sight (and I've fall into this trap too) agile seems like a way to separate the competent from the incompetents, the ones who 'can be agile' from the ones who don't.
   
   But as experience has shown me, each person is unique and has her own pace. Recognizing and respecting this is what will bring the best out of them, both individually and as a team.
   
   What does not mean, of course, that we shouldn't demand commitment from them, nor raise the bar when hiring new people :)

   Reply

2. Back to top

   Missing info

   by Jim Leonardo

   There's two possible reasons:
   1 -under performer
   2 -constant underestimation of the areas this person works on.
   
   Very often, what looks like lower productivity is a function of not understanding the system you are working in. I've run into issues in the past where strange ideas get created from statements people make...example "we average 4 hours to fix a bug" gets understood by some people to me "we shouldn't ever put down more than 4 hours for the time to complete a bug".
   
   Short of it... make sure you understand the person's REAL productivity before you start worrying about what's coming up on reports.

   Reply

3. Back to top

   Re: Missing info

   by Mark Levison

   To be fair this comments were made in the original discussion and also my blog post: www.notesfromatooluser.com/2009/01/do-you-suspe...
   
   However Mike did face the uneviable task of summarizing a monster something had to be left out otherwise he would still be writing.

   Reply

4. Back to top

   Re: "Individuals and interactions", remember?

   by JAVAID ASLAM

   Agile isn't about turning people into coding machines. We must always be aware that we are talking about human beings.
   ...
   
   :)

   
   An excellent point! It is unfortunate that people have started measuring everything in terms of lines of code. What happens when the whole project is scrapped because the "design" had not been captured correctly?
   The worst part of Agile practice is "Design == Code".

   Reply

• Older >