Reading some posts on the web, I’ve found this one, written by Liz Keogh, which talks about perverse incentives, i.e. , situations when an incentive is given to reach some goal, but instead of helping, it works against the objectives of the people who proposed the incentive.
I agree with all Liz has said on the post, and while reading the post, I couldn’t help but thinking about something that was written in The Goal, a book I’ve read a while ago:
“Tell me how [and when] you’ll measure me, and I’ll tell you how I’ll behave”
I think this sentence says it all. People should be very careful when proposing ways to measure and (especially) evaluate persons. What they don’t realize is that the metric that is used will define how the persons will behave when trying to perform their jobs.
If you measure tests written, you’ll have lots of tests , if you measure number of bugs found, guess what you’ll have?
So what I should measure? How should I rate my employees? Well, that’s easy. The only metric you should use is the ultimate goal of your company or team, as broad as it can be. And that’s one of the reasons why I believe agile projects work, because the main metric that is always used, is the business value delivered to the client (ultimate goal, remember?).
I’m not saying that people can not use all kinds of metrics, like code coverage or any other, to develop software. I’m just trying to explain that all the other metrics, besides the goal of the project, have to be used as secondary way to see if the project is going fine. There is no benefit in having a 100% tested code, if you can not deliver any business value to the customer. What is he paying for?
So, as a last thought, when you are thinking about incentives, think with care, and make sure the incentives you are giving aren’t going to be perverse!