The subject of determining compensation for developers on Agile teams comes up from time to time on the mailing lists. I’m no HR specialist, and I don’t have any easy answers to this question. It seems certainly true that some people will have provided more value than others and should therefore be given more reward. It is also certainly true that if the reward system is geared only toward individual achievement, then teamwork will suffer. Beware the law of unintended consequences.

There’s a whole class of arguments, however, that can be discarded rather easily. Those are the arguments that suggest the work should be arranged in a manner that makes personnel evaluation easy. This is pure BS! Surely a company doesn’t undertake a software development project for the sake of evaluating their employees. No, the purpose of the project is to gain the business advantage of having the working software at the end of the project.

This means that any argument suggesting pair programming is bad because you don’t know which of the pair did the better work, or that collective code ownership is deficient because you can’t judge the developers by the quality of their output, is inherently flawed. First figure out how best to develop the software, then how, in that context, how to compensate the developers.

What’s a good compensation system? It may be easier and less “numerically objective” to develop one than you think. I’m always suspicious of schemes that try to reduce the reward system to a numerical algorithm without any subjective judgment. Sure, that makes it easier, but not better. I’ve always thought that the concept of paying on a share basis, like whalers were and some fishermen still are, has a certain charm. In such a system, the shares were not equal, but the survivors of the voyage shared on a percentage basis in the profit generated. It is left as an exercise to the student how such a scheme can best be adapted to your software development project.

When developing or modifying your compensation scheme, you would do well to consider David Maister’s list of criteria for a good compensation system. It provides a good starting point without some of the a priori biases I’ve seen in some other suggestions.