Measuring development teams

measuringIn each profession there has always been the urge from management to measure the productivity of employees and software development is not different in that. Over the 12 years that I am professionally involved in software development I have seen different attempts to measure teams or individuals on their performance in:

  • Lines of code produced
  • Bugs solved
  • Bugs created
  • Amount of features completed
  • Hours worked

I totally understand that management wants to measure teams but the first thing to ask yourself is what you really want to know. All too often teams or individuals are measured on metrics because those are the metrics that they can measure and not the metrics that they need to measure.

Going after the metrics that can be measured instead of the metrics that should be measured usually results in measuring things that the team(s) see as a burden instead of something that can help them. The result of this is quite often that the team starts gaming the metrics which results in even less useful information from these metrics.

To measure what actually matters you will have to start with the basics and the basic measurement for teams should be the happiness of the employees that work in the team and the happiness of the customer that works with the products that are delivered by the team.