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? Send me a tweet at @olbpetersson :)