I was thinking about the following scenario: the big boss comes to an XP team and says, "We have to cut back the least productive performer." How do you tell?
An interesting aspect of XP is that everyone on the team knows about everyone on the team's individual performance- how many tough tasks they take, how many iterations they hit their estimates, how conservatively or aggressively they estimate. The customer and the manager only see the team's performance- do they hit iterations and releases.
Is this true or false? A good thing or a bad thing? --KentBeck
But isn't it really the whole team's failure whenever an estimated deadline is missed? A minimal level of skills is probably required for membership on an XP-like team. But beyond that I'd measure the quality of a person's collaborative behavior as opposed to their individual performance. Which is another thing that is easy to tell when the norm is constant and open change. --ScottJohnston
If the team is signing up for tasks, everyone knows, including the manager, who is keeping their promises, who is doing hard stuff and easy. The reality is that there will be developers who can do more per unit time. The reality is that there will be a member whose release will be least harmful. The developers will certainly have the data ... they may or may not agree. Personalities do exist, and color people's notions quite strongly even on an XP team.
Of course the coach/mentor feels responsible when anything goes wrong. However, the individual still has responsibility for his tasks, and if over time he hasn't learned to estimate accurately, he hasn't learned to ask for help when he needs it, and he can't take the lead on hard tasks, then he can't.
Of course the team is responsible too, and a perfectly functioning team would somehow arrange for everything to get done, i.e. for estimates to converge on actual. And still they'd know people's strengths and weaknesses.
An interesting experiment would be to address the entire team: "I need to cut one person, I need to save $78,000. Tell me how if you can. If you can't, I'll decide in my own inimitable fashion."
On the other hand, a man shoots his own dog, or something like that. It might not be fair to ask the team to offer up one of their number. What's that old thing about "when they came for the Jews, I said nothing", that ends up "and when they came for me ..."? --RonJeffries
On the other hand, you could ask for a volunteer or look for someone who might be planning to move on anyway. In most organizations, there are usually a few people making plans and looking at opportunities elsewhere. It would be nice if there were lead time. "Starting in August, we can only staff five developers." By the way, how do you do PairProgramming in an odd team? Um, a team with an odd number of members?
Are you assuming all team members are paid the same? If there's a variation in performance one might naively expect that to be reflected in salary. Sacking your least productive member would minimise impact on the team's productivity, but would also make the least savings.
Who is the employee who delivers least value for money? If you cut their salary so that someone else takes that role, what then? -- DaveHarris
I've been reflecting about this question. In the great majority of cases I've seen where projects have cut staff for budget reasons, it has been the beginning of the end. The monies, whether expenses or revenues, have been mismanaged, generally not by the team. Management has made mistakes and development is being asked to pay for it. The result, all too often, is that people begin watching their backs, worrying about their individual performance, positioning themselves unnaturally.
In the worst case I ever saw, I admonished remaining team members to take care of each other. Two of them did. The third began this amazing Dance of Helpfulness, positioning himself as able to do anything, willing to do anything, volunteering for everything, taking on tasks for which the others were better qualified. It worked: his job lasted literally weeks longer than the others.
Sometimes the project will continue ... sometimes the team will continue, even rebuild spirit. But when one of your own has been sacrificed for something none of you did, it will generally damage the team. Somehow the Marines may come together and become a stronger team when one of their buddies gets it. Programmers, in my experience, do not. Today is not a good day to die.