One question that seems to come up again and again, with unfortunately greater frequency given the realities of lay offs in the current business climate, is: “How do we use Scrum to measure individual performance?” The short, and admittedly unsatisfying, answer is: “We don’t!” The team is a single unit in Scrum that succeeds or fails as a unit. We measure a Scrum team’s performance by how they make and meet their commitments, most importantly through regular inspection of working software (which is our sole measure of progress in an agile context). When we commit to doing Scrum, we commit to doing things a different way. We commit to a different set of underlying assumptions about the most effective way for human beings to do creative work. We move from a culture of individual competition to group collaboration. And we change the way we measure success.
My colleague Angela Druckman had this to say in a recent discussion we had about this issue: “If managers would put half the effort into getting their teams to work as a unit as they do trying to ferret out laziness, they would have much more effective Scrum teams.” In other words, it is far more important to help the team achieve its goals than to try to “optimize” the team by searching for the weakest link.
In fact, scrutinizing individual performance on the assumption that there is some member of the team holding everyone else back or that someone on the team is expendable fundamentally undermines Scrum’s values. If we are really going to embrace the principles of self-organization and self-management, it is the team’s responsibility to deal with issues such as a team member not pulling their weight.
Separate from how inimical measuring individuals is to Scrum success, figuring out a metric to measure an individual working on a team would be problematic, even if we wanted to. Human beings cannot, by their nature, be reduced to a number. The literature on such topics as standardized testing or measuring intelligence is rife with controversy as to whether measuring people in that way is any kind of predictor of future success or real educational progress etc. More often than not, the answer I’ve seen is that it isn’t.
This reality is compounded when dealing with a team of individuals working in a highly collaborative way. What determines who on the team is exhibiting the highest performance? Is it the person who burns down the most task hours in the sprint backlog? Is it the developer whose code has the fewest defects? Is it the QA person who finds the most defects? The interconnectedness between various team members and their work, which we strive for in Scrum, makes it virtually impossible to then separate them out in order to measure individual performance. Scrum teams are complex and organic. The team member who burns down no task hours may be the one who resolved the team’s serious impediments that sprint, allowing everyone else to perform at their peak. The team member who has a low defect rate may have a peer who reviewed his code to thank for that. The QA person who didn’t find many defects may have been the one urging everyone else on and motivating them to succeed.
In the end, the belief that we can measure an individual team member’s performance in a way that meaningfully captures what they really mean to their team is predicated on a fundamental misconception that the whole really is just the sum of its parts. For complex systems like a Scrum team, that is patently and demonstrably false. Instead of assuming that there is a weakest link and that the removal of which will strengthen the chain, we should recognize that Scrum teams are a complex and interconnected web of skills, talents, values and creativity and, further, that the team is in the best position to judge the value of each of its members. If there is any real “dead weight,” the team, not a manager, will ferret it out, will eventually tire of carrying it, and will either encourage better performance and lasting personal change or ask for that team member to be removed.
And if the issue is solely financial, as it increasingly in these days, we should look for alternatives aside from just removal of a person from the team. There are places to cut costs besides just salaries and, even there, the team may be better off in the long run if each member makes a small sacrifice, rather than sacrificing a perfectly good team member just to save the cost of their salary. A really functional and cohesive team that believes in Scrum will almost certainly choose the former over the latter. I am a big proponent of compensation strategies that A)tie compensation partly to financial performance so that a team that delivers a result with a financial gain for the organization results in financial gain for the team and B)compensates the team as a whole (either we all get a bonus or none of us do). Taking this approach supports Scrum values, provides motivation and virtually guarantees that the team won’t tolerate any of its members who are not contributing, thereby resolving the problem of a low performer (if there is one) on their own.
Jimi Fosdick
CST