In the past couple of days on the Scrum Development mailing list an interesting thread has developed around what to do with a poor-performing team member.
Too my mind there have been a number of key takeaways:
- Be very careful about the language you use: Strong language implies prejudice and assumptions.
- Reset use a Beginner’s Mind.
- Does the team perceive this to be a problem?
- Possible causes of this perception.
- Measuring Individuals doesn’t work (nor does measuring teams, but that’s a different topic).
If it is a real problem how to handle it.
Strong language like “Rotten Apple” “Ruins the team””drag on productivity” etc. imply that you’re already convinced the person is the problem. Unfortunately, this can just be prejudice. Linda Rising, author of “Fearless Change: Patterns for Introducing New Ideas“, notes that people will categorize or stereotype other people in a very short period of time.
“In many cases, a supervisor “determines” the ability of a worker in about three weeks, labelling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice.”
In such a case like this consider using Beginners Mind (courtesy of Jean Tabaka and David Hussman). Let go of the outcome, take a step back, ask why not how, bring silence listen, and observe. The key is finding a way to let go of previous conceptions and reexamine the situation from scratch. How is this person working?
Remember the Star Wars quote (thanks to Paul Hudson):
Obi-Wan Kenobi: So what I told you was true, from a certain point of view.
Luke Skywalker: [incredulously] A certain point of view?
Obi-Wan Kenobi: Luke, you will find that many of the truths we cling to depend greatly on our own point of view
Does the team see the problem? Do they work with this person or avoid them? Are they making jokes about the situation? Behind the person’s back? Is this person included in lunch, coffee breaks, and water cooler conversation? Has the team raised the issue in retrospective? If the team doesn’t perceive a problem, then maybe they see the situation differently than you do.
Assuming there is a productivity issue, examine what they’re doing and see what the possible might be:
- Personal problems at home (new kid, divorce, family member is sick, …)
- Maybe they underestimate tasks.
- Maybe they’re very careful and leave no loose ends behind.
- Perhaps they act as glue for the team, holding the team together by communicating ideas and solving little problems. All the stuff that goes unnoticed but really does matter.
- Maybe they’re just slow by nature
- Maybe this person knows much less about the problem domain, technology etc than anyone else does.
- Maybe they’re bored, and this will come out in your one-on-one’s (see below).
- Maybe they really are a slacker.
We also hit the problem of measuring the individual’s performance by using the number of story points they completed during the iteration. This was a troublesome topic for any number of reasons:
- Measures of people are entirely subjective
- No meaningful way to measure productivity or even skills
- Measures like this are too easily gamed
- It doesn’t take into account anytime the person may have spent pairing, studying, removing impediments etc.
Possible Solutions to the problem (if it really exists):
- Pair with the person yourself. It will give you a much better idea of how they work.
- Have a one on one with this person (if you’re not already doing it, then make it a team wide habit first so that you’re not seen as singling the person out). Ask them how they perceive their own productivity. Maybe they do things, that you don’t see.
- Put together a plan to solve issues that both of you can agree on.
- If none of this works ask the person what they want. Maybe the person feels out of place on the team.
- Consider letting someone go only after all avenues have been exhausted. When this happens, I consider that I have failed.
So before we rush off to action:
- Stop, let go of preconceptions
- Re-examine the person’s role on the team
- Listen/Watch – don’t measure
- Only if there is a problem – then solve it.
For a great deal more on this and related topics you might like a book by Johanna Rothmann and Esther Derby: Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers).
Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.