Metrics = Financial Bonus
My company has just recently started wanting to use metrics to determine financial bonuses rather than employee/manager reviews. This works fine for the sales department and customer service. They can track the number of phone calls and sales that are made.
We have just started using the SCRUM method in our development process. The other manager and I are not sure what type of metric we want to start tracking to determine what kind of bonus our employees receive. We do not want to motivate the wrong behavior.
What have you measured that worked for you?
Personally I think that generic metrics are pointless, if for no other reason than (as Phil mentions) they are easy to bend to make you look better.
As for doing so in SCRUM, then things like velocity are potential targets but I refer you to my original comment.
In my experience when you tie metrics to money you will invariably have the system rigged from both sides. In other words it is pointless to do so, it is a golden carrot for the R&D staff.
In sales, which has tangible and concrete indicators and metrics to measure them then it can be done. In software development due to various influences and factors it doesn’t work for performance based motivation.
That has been my experience. Do I believe in metrics, yes (and this isn’t a contradiction from before, here me out).
===
The type of metrics for software development (Code Churn, Code Complexity, Requirements Coverage, Test Coverage & Completion Rate, Support Incident Report rates) and defect management (Fixed/Found rate, Defect Density, Recidivism (return) rate) are useful when used in the context of determining readiness, stability and reliability of the software. These are project level metrics, not individual performance which is when things get screwed up.I worked somewhere that had a “metrics” bonus system and I never once received a bonus in the four years I worked there. Honestly, I think that if you find that the metric system isn’t giving anyone bonuses you should re-evaluate which metrics you are collecting.
Any time anyone creates a metric, there’s always some kind of skewing going on. Metrics are usually created for people that want the metric to reinforce some kind of agenda. The influence of those agendas invariably makes the metrics useless as any kind of truly objective measurement.
Example:
Manager #1 decides that he wants to peg financial incentives to numbers of defects found. He has a report jockey write a report that gives him all of the issues logged in the defect tracker by associate by year.
Manager #2 finds out about this report and realizes that the sum total of defects for the whole department by year would be a great lever to get more personnel - the number of defects keeps rising, we need more people. They decide to publish the sum total to their superiors.
Manager #3 (in IT) gets chewed out because the number of defects is consistently rising. He finds the person responsible for the report and demands that “suggested improvements” not be counted in the report because they’re not really defects.
Now Manager #1 is basing his incentives decisionmaking on defects that exclude improvements, which was not his intention, but he may not realize this. Not only that, Manager #2’s request for more associates is denied because the number of defects has gone down 25% since last year.
Every single number in any kind of management report goes through this kind of neverending revision. None of these reports are known to the testers that are being reported upon, but nonetheless the metric has been made useless by managers wanting different things. The reports are “accurate” but they never quite get to the point of telling managers exactly what they want to hear - which in turn is something very different from what they say they want to know.
Tags: business metrics, company metrics, finance metrics, metric program, Metrics, scorecard
