Should You Measure Teams or Individuals?

How do you measure performance? Should you be measuring performance at the team level or the individual level?

The use of autonomous teams in Agile development leads many to conclude that team is the only concern. The case being made is this: If you focus on individual goals and individual incentives, you will cause individuals to operate in ways that are counter to the collaborative teamwork that you seek.

Likewise, there are times when individuals resent having their performance strictly assessed at the team level. Sometimes people are assigned to teams late in the game, or are temporarily taken off the team to deal with a critical issue that limited their involvement with the team. Fair enough.

Resentment can surface in another way, as pointed out by Morten Hansen in his book, Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Results: “People working in teams can shirk and get by because individual output is not being measured, only team output.”

Morten notes that when people can hide, they often do. It’s called social loafing. People on the teams, however, know how much everyone is contributing, which is where the resentment comes into play. (The daily standup with crisp answers to the 3 questions combined with the collaborative nature of Agile teams definitely helps to address this issue.)

Jurgen Appelo discusses his thoughts and experiences with the team/individual measurement in his book, Management 3.0, lamenting that, “Sometimes it seemed my only reliable metric was the steady number of complaints from people about the metrics.”

Jurgen also brought systems theory into the equation, citing the Sub-optimization Principle:

“If each subsystem, regarded separately, is made to operate with maximum efficiency, the system as a whole will not operate with utmost efficiency.” - General Systems Theory (Lars Skyttner)

Does this bring us back to measuring the team only?

No.

Avoiding sub-optimization relates to work, not measurement. As the sub-optimization principle correctly points out, maximizing individual productivity can adversely affect the performance of a team as a whole, and that is precisely what we want to avoid in Agile development.

Measuring, however, needs to be done with care. We need to avoid the use of simple measures that are taken in isolation and used as THE measure of an individual or team.

When you are dealing with complex knowledge work – like software development – over-emphasizing a simple metric will not provide any value and it can even work against you, like my oft-used example of measuring lines of code. You will be gamed because you are driving people or teams in that direction. You want lines of code? You’ll get them, but the net result will not be an improvement in effectiveness.

I agree with Jurgen, optimize the whole, but measure at all levels. Although these days I prefer to use the term diagnostic as opposed to measure (or metric).

Talented individuals need to come together as a team, and this means that people need to have the knowledge, skills, willingness and desire to make an active contribution to the team, and to do so by being cooperative, collaborative, supportive team members. Winning teams are comprised of members who are willing to help the team reach its goals above their own desires. Teams in turn need things like a clear, definitive purpose and some structure and agreement in how they approach their work and how they will gauge their results.

There should be a team first, individual second mentality, but team first doesn’t mean team only! There needs to be a multi-faceted, balanced perspective.