¡Hey! We are back.As promised, in our last post we said we would be  a series of posts on Metrics, we are starting out with the white belt

Metrics White Belt

With that said, I would like to share a quote and a definition with you.

First, I’d like sharing a quote, which, in my opinion has to do with this post and it belongs to Lord Kelvin and goes like this:

“I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers,your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be.” Lord Kelvin, 1883

Now, let’s go over a definition:

“Measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way as to characterize them according toclearly defined rules.” N. E. Fenton and S. L. Pfleeger, “Software Metrics: A Rigorous and Practical Approach,” 2nd Edition Revised ed. Boston: PWS Publishing,1997

Lack of visibility in software projects is well known, sometimes because of an organizational matter, sometimes because it is a matter related to a specific project. Whatever the case it may be, metrics should be used to shed light into processes within a continuous improvement framework, that is, if the information we are getting out of them is valid.

You may be wondering what valid means, well, simply put, metrics must provide a trustworthy value of what is being measured, otherwise, the stakeholders in charge of making an informed decision, would be using for that purpose, information which to a certain extent is invalid, and, which could all just be ´smoke and mirrors´.

From my experience, the metrics framework in some organizations, were just as reliable as a white crayon or a flat tire.

For instance, there was this one place, and it was solely focused on having metrics meeting a quantitative approach, therefore, their measure for quality meant:

  • Executing an indiscriminate large amount of test cases,
  • Doing that in a laughable short period of time, and,
  • With an ever lesser amount of people in the team.

From that experience, the validity of the results available in the metrics, were:

  • conceptually weak, because, even though we took measurements, none seemed to consider what it was that we were measuring for improvement, and,
  • operationally weak, because the tool we used to retrieve results and complete the daily report, as well as the weekly report, was not making the experience any easier.

On the other hand, I can tell you one thing, that to a certain extent might be deemed positive, and it was that, they were trying to take a measurement of something that was correlated with the end result they wanted.

What makes me say that? Well, despite all of the bad habits they had, and everything I shared earlier, the numbers they got each time, though very scarce in value, were still good numbers for them.

To sum up, there are plenty of overly simplistic metrics that are far from capturing the essence of what they are supposed tomeasure. It is much more common that people will implement a measurement framework based upon a quantitative approach, as opposed to a qualitative one, with which not only can we obtain more meaningful data, but also, more useful results within a continuous improvement mindset.

So, what have your experiences been with metrics? How have you dealt with them before? Are they a necessary evil or a powerful ally for you? In our following posts, we will continue to explore them, as well as give pieces of information and tips we have found useful to throw light on a project. ¡Stay tuned!