Detailed metrics are not always the answer

An element that is very present in almost all organisations I know are the metrics that are embedded from beginning to end. To be able to start a project, you need metrics that foresee the future. Owkay. During the actual execution of the project you need to send out status metrics, which is usually a guessing game. And once the project is finished, your starting metrics are compared with the actual ones, to create new metrics. We have a tendency to measure anything and everything, and stop asking us why we do these measurements.

Here’s a recent example of how we struggle with metrics. One of the current scrum teams I am coaching is struggling with the minimal metrics within the scrum framework. Being so used to have to measure anything and everything they do, they are uncomfortable with the tought that the relative estimation of planned stories and the subsequent velocity measurement are the only metrics showing an exact number. The idea that a relatively stable velocity already takes into account the unplanned work coming into the team is unacceptable to them. They want to estimate that work, they want to put a value on their work, and they want that value to be numeric. And even though they wanted to measure everything, they completely passed by the reason why in scrum the burndown chart should gradually go down throughout the sprint.

They are confused when I tell them the goal of the burndown is not getting to 0 in the end, but that the metric we’re actually interested in has nothing to do with numbers but the behaviour of the graph.

Also, scaling a metric like the relative estimations used in agile is usually a tough nut to crack within larger organisations. Since most teams only estimate low level stories, it’s hell for finance to try and get an estimation on the cost and budget they need to allocate, or even try to predict the ROI of a product or development. But scaling is perfectly possible when you are using the correct metric for the job! To get to the right metric for you, one should experiment, inspect and adapt. Is this the right measurement? Why? Is it showing what I want to know? Is it clear to everyone who contributes to the result of this metric?

To avoid measuring the wrong things, here are some rules to adhere to, which are clarified in more detail in the Management 3.0 workouts:

1. Measure for a purpose
2. Shrink the unknown
3. Seek to improve
4. Delight all stakeholders
5. Distrust all numbers
6. Set imprecise targets
7. Own your metrics
8. Don’t connect metrics to rewards
9. Promote values and transparency
10. Visualise and humanise
11. Measure early and often
12. Try something else

So how can you get this new way of using metrics to be accepted in your company? 

1. Find a new set of metrics, learn and adapt to your situation.
2. Evaluate the things you measure regularly and see if they help you learn to improve toward your purpose.
3. List all your stakeholders, including teams, and check if you measure for each of their perspectives.
4. Visualize your metrics and keep them close to where the work actually happens. (cfr team burndown available to the team at all times)
5. Be transparent about your metrics. Show them to others and ask the same courtesy from them. Discuss it all together, and feel free to collaborate and compete on measures.
6. Now scale this to the whole organization, where everyone maintains responsibility for their own measurements

For more information on how to change your metrics, check out this blogpost on the Co-Learning blog or attend a Management 3.0 training course!