You Get What You Measure

It is a well-known fact that if you measure the wrong things, you encourage wrong behavior. Software teams suffer daily because their managers are tracking and measuring them against the wrong parameters.

For example, measuring how many hours someone works encourages team members to clock in longer hours. Studies have show that working longer hours does not necessarily produce better results. In most cases, it actually results in poorer work quality.

Similarly, measuring and focusing on the team's velocity (amount of functionality completed by the team in a time span) encourages more work to be done faster, but does not necessarily ensure the most important/critical work is being chosen. Therefore, this approach does not solve the real business problem of completing software development both quickly and bug-free.

Focusing on how many bugs the testers report encourages the testers to report more bugs, but not necessarily to report issues with maximum business impact. If developers are measured based on how many bugs were filed against them, testers can become their enemy. This leads to unnecessary team tensions.

In my experience, more software, done faster, does not mean successful software. Rapid software development is good for getting feedback quickly, but building real products needs a lot more than just development speed.

Often when I visit dysfunctional teams, it turns out that the teams were measured using the wrong parameters. Hence the team adapted and optimized itself for those poorly chosen parameters. Lacking the understanding of the project's purpose or vision led to team members defining their own success criteria and measuring themselves against their own respective, disconnected, dysfunctional parameters. Incorrect measurement does more harm than good.

Good project managers ensure everyone on the team really understands what success means. They help build a common vision and shared understanding within the team. They encourage team collaboration by building win-win situations, so that each team member has the same focus and is working toward the common goals. They help the team identify what really needs to be measured. The secret sauce of successful projects is in using metrics as a means to an end and not as a deliverable in their own right.

I find if I try to measure 10 different things at once, it gets very confusing and distracting for the team. Limiting myself to measuring two or three parameters at a time, however, is very effective. These two to three parameters should be unanimously decided by the team based on current issues hurting the team or on risks that the team feels will impact them in near future.

Once the issue is resolved or the risk is mitigated, the team should remove the old checks and replace them with new items added to their metrics. A team which does not periodically change its metrics is symptomatic of a bigger problem.

Be sure what you are measuring is of value, and that may change during the project. You get what you measure, so be sure you are measuring the right things.