In a series of 12 blogs on the topic ” 12 Factors: Building for DevOps Success”, DevOpsGuys CEO James Smith explores the most important factors for DevOps adoption, in the hope of sparking conversations and future learning. In Blog #1 “Identify the outcome”, James considers how understanding what your organisation is trying to achieve by adopting DevOps, is crucial to its success.
I’ve been exploring what I consider to be 12 important factors of DevOps adoption which should be given consideration. These factors have arisen time and again during discussion, and continue to be a topic of both passionate agreement and heated debate.
Over the last three years growing DevOpsGuys, it’s been an incredible experience working with great people, who everyday further this discussion, by applying originality within our client base and utilising these great ideas to grow our own company. At DevOpsGuys, we’ve spent a lot of time adopting these techniques to build our own organisation, with a belief this first-hand experience will help us and others to understand and explore what’s possible.
My intention with these articles has never been to create something that is considered prescriptive, but to simply tell a story, that I hope will stimulate a conversation.
I’m sure there are many more factors which you will consider of higher or equal importance over the list I’ve compiled, and so I view this series as the beginning of a learning experience.
In this article, #1 of #12, I explore why understanding what your organisation is trying to achieve by adopting DevOps is so crucial to a successful adoption. Simon Sinek, would be pleased, I’ve started with “Why?”
#1. Identify the outcome
“Success is not checking a box. Success is having an impact. If you complete all tasks and nothing ever gets better, that’s not success.”
Christina Wodtke, OKR Coach
DevOps adoption is fraught with challenges and one of the most frequent, I’ve experienced is the deliberation that arises from the common first question; “How does my organisation get started with DevOps?”
My response to this question has always been to fall back on an answer that’s [un]suitably vague. Not because I don’t have an opinion, but because my opinion is simply that. My opinion. In fact, I have plenty of real-world examples on which to elaborate any number of behaviours and technologies I’ve seen work successfully, across a whole range of different and diverse organisations. Some, maybe all would work beautifully for the inquirer or an equal possibility is that they could spectacularly fail. I am sure that none in their own right is the silver bullet being searched for, which I suspect is the underlying context for some when they pose the question.
I’ve experienced organisations starting their DevOps journey who have leaned towards a technology adoption, and some organisations start by working towards desired behaviours. However, a number of common challenges quickly arise from both these approaches;
- The changes don’t deliver expected benefits, or the benefits are hard to articulate under early scrutiny.
- Associated behaviours and technologies do not reinforce each other.
- Changes become disjointed and competing.
It’s my belief that these issue arise from a lack of cohesion between the core ingredients; behaviours and technologies and the desired outcome they are trying to achieve, in essence the lack of shared goals, or a failure to understand why these behaviours and technologies are important.
Let me explain.
I love to cook. Specifically, I love to cook southern style US dishes. Anything that’s prepared in under a week is fast-food. Days of marinating, hours of slow braising and minutes from fork-to-mouth is what I consider heaven.
Typically, when we cook, most of us will start with a recipe. That is, a defined idea or outcome of the dish we’d like to make. To achieve that outcome, we need a set of ingredients. Every ingredient in our dish, has merits of its own, heat from Chilli powder, sweetness from Muscovado sugar and so on, but the combination of these great ingredients is what builds our outcome, in this case a tasty dish, which in some cases resembles the picture that first caught our attention.
Without that recipe, we could have combined those ingredients in any number of different ways and ended up with any number of different dishes, some tasty, some inedible. However, we wouldn’t have achieved our outcome of making the dish we set our hearts on, and if we did, it was luck rather than by design.
The other important consideration to note about the recipe we are following, is that it’s someone else’s interpretation of what tastes good. It’s a guide based on the chef’s preferences, which may or may not reflect our own. If you like more spice, double the chilli, if you like sweetness, double the sugar, the ingredients stay the same, but their application within the dish is now balanced more to suit your preferences. However, the overall outcome is still basically the same, only how we got there has changed, and as we learn more about the ingredients, our capacity to experiment with the dish increases, and the more opportunity we create to tailor it to our unique tastes.
It’s my belief that this analogy applies equally to DevOps. I consider DevOps to be the combination of behaviours and technologies that drive a valuable outcome within an organisation.
The behaviours and technologies are our ingredients. Ingredients defined as Continuous Integration, Retrospectives, Ansible, BDD, Terraform, Servant Leadership and so on. Every behaviour and technology has unique and valuable merits of its own, but it’s the combination of those ingredients that builds our DevOps dish. How we combine them, the quantities we use and when we add them to our dish is the recipe that is unique to our organisation, and only through experimentation can we learn how best to combine them.
All too often, people get caught in the trap of starting with the ingredients they want to use, with little idea of the dish they want to create.
And so the first question we should consider asking, is not “How does my organisation get started with DevOps?” but “What outcome(s) does my organisation want to achieve by adopting DevOps?” or rephrased. “Why does my organisation want to adopt DevOps?”
It may seem obvious, but this key step is often missed by many organisations as they rush to adopt Automation or reorganise a team, in pursuit of “DevOps”, forgetting to stop and ask “What are we trying to achieve?”
By first considering the outcomes, we set a vision of what our DevOps adoption is trying to achieve. Organisations often consider faster-time-to-market for product launch or features, great availability for core services or an increased capability to experiment with changes in the hands of real customers.
Whatever outcome is chosen, it’s vital to ensure that it’s valuable to both the business and to IT. This mutual benefit means that adoption is likely to incur less resistance when building the case for funding or approval.
Once the outcomes are established, the work of assembling the right ingredients, behaviours and technologies, can start. Consideration should be given to capabilities that exist within the organisation and to those which will need to be developed or bought-in. As with most great dishes, it can often be useful to start with well-understood building blocks. In Italian cooking, the stalwart of onion, celery and carrot is considered to be the foundation of any good ragu. In DevOps, this can be translated into shared goals, cross-functional communication and rapid feedback loops.
Once behaviours and technologies that achieve or reinforce the outcomes have been identified, the process of understanding how to knit these ingredients together begins. This is the building of the recipe. All great recipes have been developed through experimentation; a willing to commit to trying something, learning from it and adapting accordingly, with the aim of better meeting the needs of the consumer, or in this case the organisation.
The path towards delivering the different outcomes may share common ground, but the priorities may change for example when trying to achieve faster-time to market versus an increased capability to keep core applications functions highly available.
By identifying the outcomes, understanding the ingredients needed to achieve the outcome and experimenting with recipes which combine those ingredients together, we have a foundation on which we can explore DevOps adoption. It’s not an easy journey, but understanding where we want to go or get to, helps us to prioritise decisions that take use closer to the outcome, and more importantly identify those which don’t.
So I ask, that if you are starting your journey, or you’re already underway with DevOps adoption, that you take a moment to pause and reflect upon this.
Do you really know the outcome your organisation is trying to achieve by adopting DevOps?
In the next article, I’ll be exploring the behaviours of inspecting & adapting, the key reason why we adopt an Agile approach within DevOps and how it builds the foundation for experimentation.
Originally published on Medium