At the 2010 Agile Grenoble conference, Alexandre Boutin and Emmanuel Etasse presented Behavior Driven Metrics: Even numbers can be agile. I liked it so much that, with Alexandre’s permission, I translated it from French to English and re-presented it today to a few people at Asynchrony. If you’re interested, you can view it for yourself (all instances of unclarity and mistranslation are mine and not the original authors’).
Among the feedback I heard and observations I made today:
- Positive behavior isn’t the same as benefits (from that positive behavior). For instance, if your metric is “number of calories consumed per day,” eating foods with fewer calories is the positive behavior, while losing weight is a benefit (and not a behavior, per se).
- It’s important to understand why you would use a particular metric.
- The metric is not the same thing as the means of gathering and displaying data for the metric. For example, a metric is “number of pair switches in a time period,” and a pairing chart (or in my parlance, “pairamid”) is merely an instance of implementation
- In the spirit of one of the core concepts — metrics are not certainty — many metrics are best understood in conjunction with another metric (to give context, etc.), especially for guidance in knowing when to start and stop using them and what an optimal level is. For example, we talked about pairing and pair switching. Deciding when to track pair switching and determining the optimal number of pair switches per day is perhaps better understood by looking at some other metrics, like product quality, code ownership, knowledge siloing, etc. When the team starts realizing the benefits of switching pairs more often, or when their marginal utility of the benefit is small, that can inform the team’s decision about when to stop measuring, or at least to have an idea of what is best.