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 Id like to share to with you.
DevOps cuts deep and wide through industries, company sizes and technology environments. Nevertheless, theres 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.
Like many of IT leaders, youre asked to not only deliver more products and services than ever before, but to do so with greater speed and qualityand with no hits to reliability or security. DevOps seems like it will really help! Butyoure 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 dont buy what those leaders are doing but why theyre doingit.
The same idea holds true when building organizational buy-in for a DevOps transformation. Simply declaring Were 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 systemsgoals 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.
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:
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 teamincluding Dev and QA:
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 cant 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. Thats 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, toodont expect to sell DevOps to everyone at once. In fact, by winning over smaller groups with specific projects, youll 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.