Why, why, why, why? Measure.

Why? According to me this is the number one question that you will continously have to answer when working with software. My experience is that people are very often really good at answering this question…one time at the start of their project! Then it gets lost in translation. In bigger projects, the people who answered the first why might not even still be in the project. So we need to keep “whying” as we go through the project.

So when should we ask “why”? Well…always. Whenever we introduce something new, this new thing will (hopefully) bring benefits as well as some quirks. That will always be the case, just in the same way as the thing that you are currently having or doing is having it’s own benefits and quirks. Therefore, whenever you are doing improvements in any area, we’ve established that the first thing we should do is to ask why. The second thing we should ask is “how do we measure this?”.

If you are changing your process, your tooling or even refactoring your code, you are doing it because you want something to get better. But what is better? If we can’t state how we will measure things, we might just end up in a situation where we are doing it differently, but we don’t know if we are actually getting the benefits of it.

So let’s have a look at some different scenarios that might actually occur in your everyday worklife

Scenario 1: Scrummish…

Proposal: “Let’s move to Scrum!”

Question: Why?

Bad Answer: “Well, it seems that everyone we are recruiting is asking if we are working with Scrum, so let’s do it!”

Better Answer: “We experience that we are often building the wrong things and the cost is huge”

Question: If moving to scrum, how do we measure that we are building the right things more often?

Bad Answer: “We don’t, Scrum will solve everything”

Better Answer: “Well a part of Scrum is the review, so let’s actively also log whenever a stakeholder gives us feedback…” etc…

But most of us doesn’t change our process frequently, this might be a more occuring example:

Scenario 2: FOTM (Flavour Of The Month)

Proposal: “Hey they released this really cool new framework, let’s use it”

Question: Why?

Bad Answer: “Well, it’s new and it’s cool and they have this thing which will allow us to play Quake in the developer console”

Better Answer: “The whole idea with the framework is to fix problem X. We have had huge issues with X and their solution seems robust and well suited for our domain… [etc.]”

Question: If we are introducing this framework, how do we measure that we are having less issues with X?

Bad Answer: “We don’t! The framework will solve all of our problems!”

Better Answer: “Well in the backlog we can label up all bugs that are related to X and then we can plot the frequency of how often new bugs are reported vs how it used to be…[etc.]”

This should also be your reaction chain when you do technical tasks, refactoring code or even adding functionality (but here the most of us are already doing this through User Story-Acceptance criteria).

The why-measure is really really simple, yet often overlooked. This is something that I believe is important on a cultural level of a company; it should be in the backbone of the company as a whole.

Do you agree with me or not? Did I miss something? Leave a comment below or send me a tweet at @olbpetersson 🙂

2 thoughts to “Why, why, why, why? Measure.”

  1. Many people I’ve worked with are very good at answering “why?” in the moment of decision. But as time goes along the answer tends to migrate over to the “bad answer” category, only in past tense. “That framework was supposed to solve all of our problems!”. The “what?” and “how?” is usually traceable in source code or other deliverables, but the “why?” is often missing. I think metrics play a vital role in documenting “why?”, but I struggle to see how you would organize it in a larger project where substantial decisions are frequent. How would you go about preserving the the answers to “why?” and organize them?

    1. I totally agree with you, many are really good tt answering the why when the descision is taken.
      If we also introduce the “how do we measure?” we will have to form a strategy of how we follow up on that first answer. Our friend Carl Engström wrote something really insightful which I did not touch in this text, another question namely “How do we detect if we fail?”

      It’s of course never easy to organize this, especially not in larger projects. However, most of what we do in our software development is not easy. Things need to hurt a little bit before we learn and become better, and that is kind of what I tried to address with the “important on a cultural level of a company; it should be in the backbone of the company as a whole.” We are every good at the hands on development cycles with several books written on agile processes. Why can’t we learn from these and try to find something that also suites the more vague “whys”

      As you’ve probably realized by now this is a “non-answer” 😛 If you have the ambition to answer the why and to organize and preserve the answers you simply must start somewhere 🙂 Which granularity should you document the answers on? How should you follow up on them? Are there different kinds of answers?

      But of course before you start your process around preserving the answers, you should ask yourself “WHY are we preserving those answers?” ;).
      .

Leave a Reply

Your email address will not be published. Required fields are marked *