Measuring Individual Performance: Can a Person Be Reduced to a Number?

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.

Download the pdf version: Measuring_Individual_Performance_blog

Jimi Fosdick

With more than 14 years of experience in product development, Jimi Fosdick has worked in a wide range of industries, including publishing, software, advertising, and the public sector. As one of CollabNet’s Certified Scrum Trainers, he conducts dozens of public courses around the world each year, helping organizations to surface dysfunction and improve processes through Scrum.

Tagged with: , ,
Posted in Agile
5 comments on “Measuring Individual Performance: Can a Person Be Reduced to a Number?
  1. Anonymous11 says:

    And the motivation for individual contributors to work hard to butress the team, if not for salary increases and/or recognition via promotions (above the market baseline compensation and their peers) is…? This is a forumla for absolute mediocrity. Teams don’t HAVE capabilties. Only individuals do. There is no motivation to excel (i.e., surpass) that is not, by definition, rooted in competition amongst individuals. The question is not how to remove a low performer (below mediocrity), the question is how to promote HIGH performance (above mediocrity). How else can you expect to produce products that, by being above average, can dominate rather than simple share any market?

  2. Justine Avera says:

    @Anonymous11

    Let me start by saying I am not in the software development field – I do insurance and risk management, and I work as an artist. In both practices I have the joy and pain of working in large collaborative teams, and this article struck a nerve with me.

    Different people are motivated by different things. I am competitive by nature, but am motivated more by internal goals than by competing with others. You have to discover what motivates each person on the team to correctly provide the right incentives to maximize performance. No one solution fits all.

    I truly believe that a team is self correcting to a large degree. When someone is perceived as not pulling their weight, another team member usually steps up and ferrets out obstacles, motivational problems, and tries to create a forum where these things can be talked out in a safe and constructive environment. If needed, the team creates a work around. If the person consistently does not perform, they are not on the next project or next stages of the project by mutual consensus. Often, the team member who is not performing wants to be somewhere else doing something else, and in many cases can be re-assigned where they are happier and more productive.

    Sometimes you need to show someone the door, no doubt, but there are other approaches that can be equally effective and maintain continuity on a project.

  3. Anonymous343434 says:

    Huh.. mediocrity or idiotic.. mediocrity works when you form teams and build them.. but it wont work for the people who are already in the software development for ages and new to agile. No one becomes WASTE overnight. The main problem with agile is that it is trying to redefine the whole software organization as well. Scrum in general came up with new set of roles instead of reusing the existing structure of organization and its roles. At one time we tell that the team is important and simultaneously we talk about mediocrity. This is just for those ego and self-minded managers to keep themselves at the top.

  4. William Roberts says:

    Measuring the team rather than the individuals is rather like optimising the system instead of the components – the “See the whole” principle.

1 Pings/Trackbacks for "Measuring Individual Performance: Can a Person Be Reduced to a Number?"

Leave a Reply

Your email address will not be published. Required fields are marked *

*