DevOps is a culture, not a role!

Software is everywhere. In today’s world, every major company/organisation is related to software development and needs to behave as one. There is more pressure than ever to move faster and be more agile without sacrificing security or reliability. This pressure often manifests itself by project being cancelled or put on hold. This is the situation where DevOps seeks to address: how to get development, operations and other groups within the organisation to collaborate around a set of shared goals, to deliver software faster and more reliably to customers and end users? Key technical practices that underpin a DevOps initiative include getting dev and ops teams to standardize on a common set of agile processes and tools for software delivery. These often include:

• Automated configuration management, testing and application deployment;
• Version control of application and infrastructure code to enable collaboration and rollbacks;
• CI (continuous integration) to automate code builds and enable faster feedback and iteration through more frequent, lower risk releases.

DevOps is a cultural perspective on how everyone should be engaged in working the right way. In a software-defined world appears a pile of questions.

How do we get something into production quickly and once it is in production? How do we know we’ve come up with the best solution? How quickly can we apply improvements and updates?

DevOps aims to include everyone who has a stake in the game by involving them early on in the collaborative process. Achieving that success with DevOps starts with understanding the key business benefits. Organisations are able to move faster with less downtime and fewer security issues.

Mike Dilworth, Agile and DevOps transformation lead, recently said:

DevOps is a culture, not a role! The whole company needs to be doing DevOps for it to work.

There needs to be backing from senior leadership, but also involvement from everyone with a stake in the final product, not just development and operations departments.

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:

1. How quickly can code move from a dev’s laptop to production?
2. 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?)
3. How often are you deploying now vs then?
4. 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?
• Change fail rate: 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.