“Tell me how you’ll measure me…” (2)

Coincidence or not, after writing the last post, I’ve just received the InfoQ newsletter, which contains this article, about bonus distribution within agile teams. And what does it have to do with measures and incentives?

Well, if you want to have some great individuals, reward them based on individual performance, if you want a great team, don’t try to establish some weird criteria, and measure everyone’s performance based on the team result.

Like Mary Poppendieck cited on her book, distribution of bonus to an Agile team is like playing with dynamite.

“Tell me how you’ll measure me…”

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!

Good News!

Enough of this developer non sense! Here is the solution:

Introducing Mingle Proj-o-matic

Regards.

The Turning Point

As you may have noticed, with the language change (from portuguese to english), I decided to also change the blog’s name, since the previous one wasn’t saying very much.

The new name is based on the book I’m currently reading (and recommend), The Turning Point, by Fritjof Capra, which can be described like this (from Wikipedia):

It begins by outlining and tracing the history of science and economics, highlighting the flaws in the Cartesian, Newtonian, and reductionist paradigms. It narrates how such viewpoints have grown inadequate for modern technology and ecology needs, then argues that science needs to develop the concepts and insights of holism and systems theory to solve society’s complex problems.

Just to show you why I am really enjoying this book, here goes a sentence extracted from it (it has been already posted before, but it was in Portuguese, so I thought about translating it… free translation from the portuguese version):

“The complexity of our technological and industrial systems has now reached a point where many of these systems can not be modeled or managed. Failures and accidents occur with increasing frequency, unexpected social and environmental costs are continually generated, and more time is consumed maintaining and regulating the system than providing useful goods and services.” – Fritjof Capra – The Turning Point

Despite being from 1984, I think this specific sentence could be used to describe the vast majority of software development projects now in 2008 (just 24 years later), and that’s why I’ve chosen this blog’s title. Because I believe that the software development industry is reaching its turning point, the paradigm is changing (not as fast as we want, that’s true), and this blog is meant to be just another forum to discuss the new ideas being proposed (and also the old ones, when they are better than the new..).

Well, that’s it. Hope you enjoy!

Cheers.