Deep Thought: DevOps Failure? DON’T PANIC!

Over the last 3 blogs we have discussed the Why, the How and the What and in those discussions we understood a little more about the questions themselves and what they mean. So now seems like a good point to start looking into some of those areas in greater detail. In the last blog we got more into the principle of “value”, in particular, “business value”. However, there is another “value” we must consider that is core to our DevOps culture, the value of failure.

We as a human race have developed and evolved over millennia, but our capabilities to learn appear to be growing exponentially. New developments in mechanics, electronics and now digital are occurring more and more rapidly. Very, very rarely have these advancements been made as a result of a single moment of genius. Most of these advancements have been made as a result of experimentation, and experimentation requires failure.

Ironically, it is possibly one of the greatest failings of the IT generation that a culture developed of “Get it right first time”. Failures were seen as huge negatives, things to be shamed, hidden and ignored. During the years of waterfall planning, I, like I am sure many of you, have seen plans drawn up around a perfect world, where the phases of Design-Develop-Build-Test-Deploy are estimated based upon a perfect vision where nothing could go wrong. Yes, maybe 10% to 20% contingency was added in, but the vision was always that we knew from day 1 exactly what was being produced, how it was being produced and that the end result would be successful. This is the complete antithesis to experimentation, which is where we know true innovation and breakthroughs come from.

The front cover of the Hitch Hiker’s Guide to the Galaxy[1] had “DON’T PANIC” written on the front cover in big friendly letters. It would seem that the same should be on the front cover of any organisations DevOps transformation. Yes, it is a big and scary change, like it is a big and scary universe. Any change is disruptive and holds an element of risk, but without change there would be no progression, no growth. If we are not going to panic, then we need to stay CALMS.

CALMS is an acronym for Culture/Automation/Lean/Measure/Share. We have already discussed a lot about culture, it is the key core component of DevOps, but as part of our transformation, not panicking when we have an issue is a fundamental part. The IT industry has lived on a culture of a “Fear of Failure” for too long. It needs to conquer that fear. The organisation transforming needs to conquer that fear. As we get into other areas in more detail, we will refer back to CALMS again in future blogs.

The greatest reason for the failure of transformation programmes is usually that fear. In changing any culture, fear plays a great part. I have known many organisations where you will hear the people complain about existing working methods, but the moment there is a possibility that it will be changed, there is still resistance, because despite the faults, it is what they are used to. It is their culture and their way of working. The ones most vocal will be the naysayers. They will have the greatest doubts and sow the seeds of fear in an organisation. This is why turning to a 3rd party can often be the best recourse for any organisation planning to travel on the DevOps transformation journey.

A 3rd party can provide an impartial, holistic and outside-of-the-box approach. A good 3rd party will first listen to an organisations Why. They will learn and understand the reasons for the journey. In pulling together the How, they will identify the fearless within the organisation, the early adopters, and they will work with them, in partnership, to start the journey. As they travel together, the 3rd party will educate and mentor the early adopters through experimentation, into being the transformation leaders and the change will spread across the enterprise, becoming the What. There may be times when things do not go as expected, but this will be part of the learning exercise and allow the organisation to grow, develop and mature. Naysayers may be lost along the journey as they are unable to comply with the new growing culture. Eventually, a good 3rd party will extract themselves from the organisation to allow them to self-develop in a fear free organisation.

A DevOps transformation is going to be difficult, and maybe at times, painful. Using an experimentation approach means that there will be dead ends, problems to be solved, or maybe the occasional fire, but remember, DON’T PANIC! The gains to be earned will be worth it in the long term.

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