Five steps to delivering DevOps at scale

So, you’re thinking of taking DevOps out of the relatively safe, yet challenging environment of the controlled initiative, and into the far less safe, and even more challenging environment of the broader enterprise? While, “if you want get there, don’t start from here,” may be a familiar adage, most organisations have little choice but to take what they have (in terms of strategy and organisation, people and tools) as a foundation for DevOps nirvana.

Given this, complex, crumbling reality upon which you already stand, how can you start thinking about broader deployment of DevOps? In a recent webinarwith myself and Nigel Kersten at Puppet, our discussions and Nigel’s hands-on insights unearthed a set of steps which I thought I would paraphrase and share. These aren’t so much a methodology as “what seems to have worked for a number of organisations” — feedback welcome, as always!

Having said these steps don’t constitute a methodology, they start with one — or at least, a method. Recognised as part of lean manufacturing and management approaches, Value Stream Mapping (VSM) offers a way of looking at processes and activities that focuses on the value of what’s being delivered, as opposed to the product or service as an end in itself. Applied to software development, VSM offers an answer to what some see as a weakness in any “let’s speed up delivery” approach: how to ensure that what is deployed meets the requirements defined for it?

Once value has been established as an immutable thread throughout software development and delivery into operations, attention can turn to making things happen faster. Standardisation offers the most gain with the least pain: simply put, it means you are only making changes to your stuff, not to the stuff everybody is using. You can start at the bottom of the stack, agreeing VM and OS versions that are going to work for ninety-nine per cent of your needs. Get these fixed, then work up the stack into libraries, before looking to standardise on continuous integration and deployment. Make the gains from bottom up.

Now, you’d expect (automation vendor) Puppet to say this, but to be fair, automation has been left until the third point! Automation means efficiency and productivity, a.k.a. doing the things people currently have to do, so they can get on with the stuff they’d like to do. It doesn’t make sense to automate tasks that don’t add value (hence step 1), nor to do so in a way that is different every time (step 2). It’s also worth automating the things that are going to make the most difference to the most people, which leads to step 4.

The Pareto principle, or 80/20 rule, has a place in most, if not all, best practice. DevOps is no exception: its adaptation of Kent Beck’s xP principle, “Enough functionality for now is enough functionality for now,” aligns with the need to standardise, automate and prioritise actions according to what is possible, viable and valuable. In terms of taking DevOps to a wider audience, do not feel you need to apply it to the whole business in one go; rather, continue to look for opportunities where it can make a difference, broadening its reach over time. Then, as Nigel Kersten highlighted, make sure authority and responsibility match, such that those in charge have a remit upon which they can deliver.

Agile principles may be well-understood inside the development organisation, but not so much outside it. Building on the fourth step, the goal is to achieve a series of small wins:each can be measured in terms of both whether the use of DevOps served its purpose, and whether those involved achieved a level of epiphany, such that they see it as the best way forward for future projects. This latter suggests the change of mindset necessary to achieve transformation, from an organisation that delivers products and services based on linear thinking, to one adopting continuous learning, innovation and improvement.

A final thought is around the need for feedback and information sharing across each step. Not only can the above help move an organisation forward, but each can be used as the basis for collaborative activity: for example, rather than one part of the organisation conducting VSM, how about involving a cross-departmental team? The scope and extent of this interworking may be dictated by what is realistic, for example based on which senior stakeholder is prepared to act as executive sponsor, or how well certain business units interact. Overall, the goal is to start delivering on DevOps as broadly as is feasible today, in the knowledge that success can be built upon tomorrow.