Someone recently described this situation on the Scrum Development list:

“…we’ve found some members of the Scrum team working extra intensely to cover for poor performing people. For example, if the strongest developer pairs frequently with the weakest developer, it is hard to determine if the weakest developer is just so weak that they shouldn’t be on the team in the first place.”

The poster wanted to know how to identify and fire weak performers on agile teams.

I’d try on some different ideas:

Perhaps the developers “cover” for this person because they value something else he/she brings to the team. I’ve run into lots of people who had “weaker” development skills but brought other strengths that outweighed that weakness. On any team, and especially when people ust collaborate closely, there are people who work “in the white space.” Things just go better when they are around, though their contribution may be harder to measure.

Perhaps the team has recognized that the so-called weak developer does need to improve his skills, and they’ve devised a strategy to accomplish that goal–having stronger developers mentor him. Self-organizing teams often reach the stage where they are solving their own problems rather than waiting for a manager to step in.

Pehaps the team is using the “beginners mind” strategy for pairing described by Arlo Belshee here. Sometimes it is very productive to have someone who knows less and asks the questions that experts don’t think of anymore–and thereby prompts fresh thinking.

Of course, I’m only privy to a snippet of the story. There may be other evidence or information that leads the poster to conclude there is a weak performer to be rooted out.

But if this team is meeting it’s commitments, writing solid code, and surfacing and fixing other issues, I wouldn’t assume that there’s some one who is too weak to be on the team.

Pin It on Pinterest

Share This