Blogi 16.8.2017

Time to Choose Your Metric: Part One

Kiva kun löysit tämän artikkelin! Se sisältää varmasti hyvää tietoa, mutta pidäthän mielessä, että se on kirjoitettu 7 vuotta sitten.

Some months ago, I organised a workshop with the theme of efficiency in software development. During the workshop, I asked participants to identify how they would like to measure bugs. In just a few minutes the participants invented more than twenty different bug metrics. If a bug tracking is only a minor part of the software development process, how can you handle hundreds of metrics and statistics?

Metrics Beat Arguments

Metrics are a vital part of learning. Without a foundation, it is impossible to know if you are improving or regressing. Metrics give guidance to your decision making and make the important information visible.
Breaking down your metrics into vanity and actionable metrics help you to focus on the essential. Vanity metrics are typically nice and easy to collect, but don’t change how you act. In the worst-case scenario (such as what happened in the Space Shuttle Challenger disaster, huge amounts of vanity metrics hide the critical data with fatal consequences.
By contrast, actionable metrics change the way you behave. Software and consulting firm Gofore’s actionable metrics are, for instance: the utilisation rate, employees’ engagement level, and clients’ satisfaction rate. To test your metric, just double or divide the value. If you need to reschedule your calendar after modification, you have found an actionable metric.

Less is More

“Can’t do what ten people tell me to do, so I guess I’ll remain the same” sings Otis Redding. This Otis Redding problem explains that too many metrics give mixed signals and require unnecessary work, and as my workshop example shows it is extremely easy to invent numerous metrics in a limited time.
Have you ever wondered why management books introduce so many four-element theories? The root cause is humans’ limited working memory capacity. An average human can remember 3 to 5 items at once. Your metrics should follow the same pattern—less is more. The Lean Startup movement goes even further. It introduces the ‘one metric that matters’ concept, where there’s one metric you should care about above all else. If the product goals changed, then the metric needs to change as well.

And the Oscar Goes to…

It is impossible to choose one metric that works on every product. The metric depends on the business model, product maturity level, and other boundary conditions. The whole Lean Analytics book focuses on how to choose the right metric for your product.
Whereas software development rules are universal, speed with superior quality is always the key to success. Typical software development metrics are velocity, throughput, burndown metrics, cycle time, lead time, work in progress (WIP), and different bug metrics. What if you need to survive with only one metric?
The essence of agile is to reduce feedback loops, hence my natural choice is the ‘time to feedback’ metric. It defines the time elapsed between the identification of a requirement and customer feedback. The time to feedback metric provides a whole software development organisation one single goal: how can we get the customer as close as possible?
My latter blog post goes deeper into the time to feedback metric and explains how you should use the metric in your software development.