Deep Thought: What do you get if you multiply six by nine in DevOps?

Arthur pulls random letters from a bag, but only gets the sentence "What do you get if you multiply six by nine?"

"Six by nine. Forty two."

"That's it. That's all there is."

"I always thought something was fundamentally wrong with the universe” [1]

Of course, six times nine is not forty two, it is fifty four. The answer is deliberately wrong. It was wrong because of the “garbage in, garbage out” principle. The "Earth" should have calculated correctly, but the unexpected arrival of the Golgafrinchans on prehistoric Earth caused input errors into the system. The same principle is true when trying to understand the 3rd question from our introduction blog, “What exactly are we supposed to get as benefits from this?”

I will now admit to being a little bit naughty. The 3 questions from the introduction were put in the order that I will typically hear them in, or in order of what others perceive as importance, however, they are the wrong way round. This question is, in fact, the very first question we should be asking. Without a definition of any expected benefit we are wanting to achieve, what is the point in even understanding the first 2 questions? Yet putting the questions to you in that order, does make the understanding of this question so much easier.

In the blog on the Total Perspective Vortex, we learned that there are many perspectives within DevOps that need to be understood. We also learned in the next blog on Building a DevOps planet that it is those perspectives that help us to define how to implement a DevOps culture. Both centered round the concept of “value”. The “value” is our benefit, it is our Why?

For those who have not had an opportunity, go to YouTube and watch Simon Sinek’s TEDtalk on “Start with why?”. Fundamentally, if you understand why something needs to be done, you are going to be bettered positioned to understand the how and the what. Take a look, it’s about 18 minutes long, but be sure you come back to this article after. Hopefully, you will see it is better to drive from a purpose behind the DevOps Transformation, rather than just to say you want a DevOps transformation. The worst reason to transform is simply because others are doing it, you need to understand why you are doing it.

Suddenly finding the meaning of this final question is so much simpler, but now the answer is not – not easy that is. Your “why” can be so different to so many others, but will typically be driven around a value. A value calculated around quality, time and cost. Quality, time and cost are differently weighted drivers for different roles, so each will have their own perspective that needs to be considered and then brought together into a universal DevOps proposition.

See what I did there? Time to go back and maybe review my previous blogs in reverse order, because now if you really know your “why”, you can start to define the value. It is those things with the greater value that will drive “how” you transform. As you transform, you learn and adapt, implementing those things with the greatest value first. As you progress through your transformation, your universe is created, meeting the perspectives of those in your enterprise and suddenly you are able to see “what” DevOps is to you and your enterprise.

It is all about delivering value. If there is no value, why are we delivering it? How do we understand if we have provided value? What will allow us to determine the value? That’s an easy answer. We measure and compare. This is a principle common to so many frameworks – TOGAF, Lean, CMMI, ITIL…I could go on forever. But the principle is the same. Identify where you are now, measure it, adapt your new principle, measure again and compare to see if it is better. The difference is a value, whether that be quality, time or cost. Is it a benefit? If that value matches your why, then yes. In other words, what you put in, your "why", will determine if what you get out, your "value", is of benefit.

Value in, Value out!

I suggest that in my next blog, we take a more in depth look at value and in particular, the value of failure. If there are other things you would like to see discussed, please feel free to comment below.

[1] Douglas Adams (1 January 1980). The Restaurant at the End of the Universe. ISBN 0-345-39181-0.