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.
Your Perception
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?
Team’s Perception
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.
Possible Causes
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.
Measuring Productivity
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.
Anna Forss says
First; I love your post. It summarize so much that is almost taboo to talk about. What I lacked was that agile development does not work for all types of developers. One guy I’ve had the privilege to work with did not come to his right in an agile environment. My just building a solution around his strengths he grew and became a better developer than ever. But had he hanged on an agile team, he would have lost confidence in himself, become worse or quit.
The problem I’ve had is when you’ve come to the point that the problem has been identified but management does not handle it.
The situations I have in mind is when a poor performer has been recruited and management does not want to handle this. In many of these cases, this was identified by one or two team members before recruiting, but this was not taken seriously. In other cases, the recruitment was made in haste and it wasn’t really thought through. Well thought through recruitment processes, early feed back, not hiring people when a team member opposes the person should be considered. Work tests and collaboration tests are good. One should never take for granted that a developer who says he has ten years experience is a senior developer. And just because he know the buzz words in agile software development does not make him an agile developer. And if the wrong person has been hired, take it seriously and have a plan for it. It does not get better by just hiding the fact.
Like always, I write too long comments. But great thanks for this post, which I’m forwarding to all my friends in a management position on agile software projects.
Mark Levison says
Anna – your comment is hardly too long.
You bring up a number of interesting points. I didn’t go into anymore detail in the post because it was already way too long.
Companies need to focus on hiring the right people and involving the right people in the hiring process.
On the other side when all else fails HR departments need to act quickly once its been demonstrated that a person can’t be helped to work in a given role.
Anna Forss says
Thanks, Mark. I just blogged on your post. I guess your prediction has come through and the blaming game has already started
https://painistemporaryfailurelastsforever.blogspot.com/2009/01/bright-lights-in-sea-of-darkness.html
Jason says
What I would be more interested in is how to correct poor performing behavior. Rather than just identifying poor performance (that’s easy) how does a team help the poor performer become a productive team member?
It’s easy to identify a problem but if you don’t have any suggestions on how to fix the problem, the identification is useless.