I used to read a white paper by Puppet about how can we build a high-performing IT-team. And Section A had a bunch of interesting theories and practices I’d like to share to with you.

DevOps cuts deep and wide through industries, company sizes and technology environments. Nevertheless, there’s a common refrain from IT-managers who are leading successful DevOps transformations within their organizations. DevOps is about continual learning and improvement rather than an end state.

Build the business case

Like many of IT leaders, you’re asked to not only deliver more products and services than ever before, but to do so with greater speed and quality — and with no hits to reliability or security. DevOps seems like it will really help! But…you’re running into skepticism your team before you have even really begun.

How do you make a clear, convincing case for DevOps that reduces fear and converts skeptics into champions?

Starting with the question above is actually a great start. Building the business case is a crucial part of a successful DevOps transformation (especially in large organizations). In a famous TED Talk, Simon Sinek notes a common denominator of great leaders and catalysts for positive change:

People don’t buy what those leaders are doing but why they’re doing it.

The same idea holds true when building organizational buy-in for a DevOps transformation. Simply declaring “We’re doing DevOps” is not going to get people on board. Instead, you need a compelling answer to the questions “Why? And why now?”. All our customers want to move faster without compromising the reliability and stability of their systems — goals that directly conflict with each other in traditional organizations. Developers are tasked with getting new features into production as fast as possible. Operations guys, meanwhile, are measured on the uptime and performance of systems. So these teams become adversaries instead of allies. As a result, deployments to production are plagued by delays and errors, and they occur far less frequently than the business really needs.

Getting Dev on board with DevOps

Faster deployments and feedback loops get to the heart of what developers want: code gets from their laptops into users’ hands much faster and continuous delivery enables rapid iteration and improvement. Tracking improvements to your change lead time during early pilots is a good place to begin:

How quickly can code move from a dev’s laptop to production? How does this stack up against your prior lead times? (Did you automate more of the build process? Did you cut down the number of tickets needed to deploy?) How often are you deploying now vs then? Have deployments becomes easier and faster?

Getting Ops on board with DevOps

Ops benefits when developers work closely with them. It can be helpful to start by agreeing on a common tool-chain and having the two groups work together to adopt the same tools used in development for integrating, testing and deploying infrastructure code. That brings developers more actively into deployments and troubleshooting, further breaking down old barriers while improving speed and reliability. Tracking several metrics that Ops cares about will underscore the wins for the entire team — including Dev and QA:

Uptime/downtime : Are you better able to meet your service-level requirements? Has downtime decreased?

: Are you better able to meet your service-level requirements? Has downtime decreased? Change fail rate : Have failures decreased?

: Have failures decreased? Mean time to recover: Have you shrunk the time it takes to roll back to your last known good state when a failure occurs?

Start small and grow from early successes.

So how do you begin to measure these DevOps impacts and bolster your business case? Start small with specific tasks and projects. This approach proved highly effective for Terri Potts (engineering fellow & software technical director at Raytheon)

You can’t change the whole program, but you can start by getting a few of your sub teams going in the right direction. It can be helpful to bring in someone from the outside to automate a few tests or builds and give the team some examples to build on.

Raytheon enabled one of its teams to shift from two integration procedures per month to running 27 of them in a single night as a result of automating its builds. That’s a big win on a single initiative, and it became part of Potts’ broader case for growing DevOps within the organization.

Start small with the cultural shift, too — don’t expect to sell DevOps to everyone at once. In fact, by winning over smaller groups with specific projects, you’ll create ambassadors who can help promote DevOps elsewhere in the organization, creating a multiplier effect. As you build your business case you should also remain mindful of potential obstacles to long-term DevOps success.