Seven critical elements to a successful DevOps transformation in 2019

(Image credit: Image Credit: Profit_Image / Shutterstock)

Ever since Microsoft’s Satya Nadella declared that all companies are software companies, we’ve seen a big shift in how businesses are using software to compete. As a result, companies are placing greater emphasis on delivering software faster to drive transformation. This emphasis places DevOps at centre stage, with a growing need to incorporate DevOps into company culture and companies’ digital transformation efforts.

When people think about DevOps transformations, for many, the first thing that comes to mind is a technology overhaul. They think of IT teams, development tools, software automation, and rapidly flowing software deployment. But successful DevOps transformations involve a much broader scope of people, processes, and tools. As companies start putting their DevOps digital transformation strategies into full gear for 2019, here are eight elements critical to success.

1.     Understand that you’re building a service

Your developers can tell you a version of the following story:

Back in the day, we would set up a Jenkins server under someone’s desk and then we’d start to use that server to build our software. More and more developers would start to use it. The problem was, when issues came up, like the server would get powered off, no one knew where it was running. That’s when Jenkins became a production-level service.

Think of your DevOps transformation as introducing a new service to all of the people who are responsible for delivering software. You need a service that is available 24/7, since delivering software requires robust, sustainable delivery from developer through production. Successful organisations think of this “DevOps as a Service” approach as a way to ensure that everyone has what they need to do their job in delivering high-quality software.

2. Establish a clear focus

The next step in any DevOps transformation is simple: don’t “do DevOps” just for the sake of saying that your company “does DevOps.” You need to become an organisation that maintains focus on the entire delivery pipeline, from developer to production. Start with a clear, honest assessment about the way you currently deliver software. Here are some things to think about:

  • What are the different release processes you leverage today? How are changes to most applications delivered from developer to production? How many applications do you currently have? How many active releases are associated with an app at any given time?
  • How do you define releases at your organisation? Is it a per-app event, or is it an outage for one night with all apps included? Try to think about everyone who has a role in getting your application running in production—Dev, QA, InfoSec, OPS, DBAs, etc.
  • What is your overall goal with this launch? Be specific. “I want to do triple the amount of releases next year” is good, but it isn’t enough. What does this mean for your organisation? Do you want to triple the number of all releases, or just one? Are you trying to increase the average time per release post build?
  • Finally, think about how you want to track progress toward your already established goals. What KPIs will you use?

3. Get executive buy in

In many enterprises, we find the DevOps transformation grows organically starting with the front-line developers and then to the rest of the organisation. To make the transformation successful, it’s important that executive leadership be involved every step of the way. Leadership must have a total commitment to the transformation, including committing time, resources, and budget. Otherwise the transformation efforts will become fractured or even abandoned.

Communication is crucial. This communication includes regularly sharing wins and their impact with the entire company, however large or small those wins may be. Share early and share often – and speak in business terms that everyone can understand.

For example: What will this DevOps success enable customers to do that they couldn’t do before? Did it allow the company to enter into a new market or line of business? Will the software help employees or partners become more efficient? Find ways to tell the whole organisation the story about the relevance of the transformation and about all the people who made it possible.

A successful DevOps transformation involves much more than getting a few small teams on board. It’s about moving the entire organisation forward, and that requires that everyone, including executive management, buy into the transformation.

4. Build your minimum viable products (MVPs)

You’re going to have to sell this DevOps transformation to constituents across your organisation. To make your changes credible, you’ll need to achieve success in production. The reality is that it’s easy to automate in development. It’s really hard to automate in production.

Here’s the one simple rule for success: 1-3 applications, implemented from development through production. By picking a small set of applications and working through a DEV to PROD implementation, you’ll achieve three things. First, you’ll have implemented the service platform, by working through any/all organisational boundaries. Second, you’ll have real success that you can measure for your entire pipeline. And third, by picking applications that have a variety of technologies and a regular release process, you’ll have credibility across multiple teams in your organisation.

5. Increase collaboration

At its core, DevOps is all about collaboration. Ensuring everyone involved in software delivery knows what everyone else is doing creates the social cohesion that drives DevOps forward. There’s no way to implement DevOps overnight, but any step towards greater collaboration delivers real benefits.

For example, follow a scrum model by holding daily team meetings where people review their progress by addressing three simple questions: What did I do yesterday? What will I do today? What might block me from achieving my goals? These meetings should be short and sweet—about 15 minutes—and include the whole team. The difference here is that instead of just focusing on technical application changes, you’ll discuss non-code topics as well. These non-code topics are critical for shining the light on all the organisational boundaries (think “people” and “process”) that deter so many DevOps transformations.

I also like the practice of what I call “dad” meetings – bringing everyone involved with delivery of an application to the table, from Dev, QA, DBAs, and ops managers to production staff and even the CIO, for a 2-to-3-hour mandatory meeting. During these meetings, each team reviews exactly what every member of that team needs and what is blocking them from getting it. A meeting like this works because, I can guarantee you, that at least one person in the room has never been asked the question, “what do you need”? Getting answers to that question forces the conversations necessary for figuring out how standardise the way you get your software into production.  

It’s critical that every team in the release delivery process is invested in the success of the project. If you haven’t taken the time to build collaboration and trust with all the teams responsible for delivering change, go back to that step before trying to actually implement changes. It’s easy to say, “communicate more.” What you really need to ensure is that people who are taking the risk to make these changes know that they are both encouraged and supported.

6. Manage your pipeline as code

Your entire delivery pipeline needs to be managed as code. This means that deployments, releases, infrastructure, and configurations need to be versioned and certified. Your DevOps service will both demand and enforce this, since delivery of changes won’t be possible by someone “logging into a server and running their custom script.”  In that example, the person would check their script into a source code repository, and the running of the script would be executed at the appropriate time by the release orchestration engine (which, by the way, would also be running versioned definitions of release modules).

7. Standardise for scale

I can’t stress enough the importance of standardising your software delivery process, particularly if you, like many large companies, are looking to shift applications to the cloud. By bringing everyone together, defining your releases and establishing goals, you’ll move away from a trial and error approach to a more repeatable, scientific one. Standardisation not only allows you to deliver software more quickly and efficiently, it positions you to set goals and then collect and analyse data that allows you to see if you’re meeting them.

The important step here is to assign metrics/KPIs to those goals and track them over time to see how successful you are or where you need to improve. That information will arm you with hard data and intelligence that will solidify support for DevOps and help you make the best decisions that will continue to improve your processes. Collecting and reporting on a standardised process also sets you up for more advanced analytics approaches, such as predictive DevOps and AI, which will rise in use over the coming years.

When it comes to a successful DevOps transformation, much is at stake. Organisations that learn how to master efficient and effective software delivery will succeed.  Software delivery is first and foremost a business endeavour—all the people, tools, tasks, and processes exist to drive business value. Harmonizing all these pieces requires expanding your approach from development-cantered to business-value-stream cantered. Keeping these eight elements in mind as you kick off your DevOps transformation will get you on the fast track to realizing this business value.

Tj Randall, VP of Customer Success, XebiaLabs
Image Credit: Profit_Image / Shutterstock