Process Programming

You Get What You Measure

This is a phrase that should pop into your head whenever you are thinking about introducing a metric to a team. You get what you measure. It really is that simple.

Most good-natured people are trying to determine whether the team is being effective or whether they are improving over time. This can seem quite hard to do, so it is tempting to find something quantitative so it can be published on a graph.

Don’t Encourage What You Don’t Want

If you measure lines of code, you’ll get lots of lines of code. It is unlikely that you want lots of lines of code. If you use velocity as a metric, it will creep up over time (not necessarily with greater throughput of features). You can be selective with metrics – create a short-term measure to boost a particular practice or behaviour – but it needs to exist just long enough to create the right habits.

What to Measure

I am suggesting that you drop simplistic metrics in favour of less tangible (but more valuable) measures. What is the subjective well-being of the team? Is the customer delighted? These measures are far more valuable in determining the effectiveness of the team and their process. They are, perhaps, a little harder to obtain.

Why measure the team’s subjective well-being? It has been proven that you can measure a drop in subjective well-being before other metrics show the impact of that drop. If you put smiley / sad faces on the cards on your task board, you will be able to predict (and possibly even avoid) the drop in measurements such as velocity and quality.