(^110) 97 Things Every Project Manager Should Know
You Get What You Measure
Naresh Jain
Malad, Mumbai, India
IT IS A WEll-KnoWn FACT that if you measure the wrong things, you
encourage wrong behavior. Software teams suffer daily because their manag-
ers 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 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 function-
ality 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 prob-
lem 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 are 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 soft-
ware. 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 mea-
sured using the wrong parameters. Hence the team adapted and optimized
itself for those poorly chosen parameters. Lacking the understanding of the