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 and 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 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 more products and services than ever before, but to do so with — 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 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 ?
  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)

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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store