With more organisations than ever before implementing DevOps as a way to provide more regular software releases, agile software delivery is gaining momentum faster than anticipated. Research conducted by Right Scale in 2016 revealed just how quickly DevOps is being adopted, with 81% of enterprises using it at the time. Despite its increasing uptake, the overall theory is still generally unfamiliar to many organisations. Therefore it is not unusual for DevOps implementations to go through failures somewhere along the way.
Here are the five main reasons why DevOps initiatives often fail, and the best ways you can fix them.
Problem #1: Failing to define the meaning of DevOps for your organisation
The definition of “DevOps” is not always clear, and can have different meanings from one organisation to the next. Developers may equate DevOps with a specific approach to software builds, using popular tools such as Chef, Puppet, Jenkins, Git or Docker. Meanwhile, IT management might see DevOps as a continuation of existing processes with an emphasis on faster time to market and lightweight release procedures.
Dalibor Siroky, CEO and Co-Founder of Plutora.
For organisations launching rockets or running economies, “DevOps” means something very different than what it means to a startup. If a software release still involves the use of a change management tool such as BMC’s Remedy, is it really DevOps? If it takes an hour to deploy a QA build, is it really DevOps?
Without a common definition, teams will argue over what DevOps is and why it’s being used. Before introducing technology and processes under a DevOps initiative, organisations need to agree on a definition of DevOps, be clear about what they are trying to accomplish and draw boundaries between DevOps and more structured approaches to IT service management.
Problem #2: Prioritising tools and techniques over your teams
The second mistake many enterprises make is to elevate technology as the primary driver of DevOps at the expense of important processes that ensure quality software is meeting customer expectations.
Content from our partners
It isn’t enough to hire a few release engineers, provide them with VMs and permission to install Jenkins and Puppet. For any DevOps initiative, the technology should not be the only consideration, people and processes also need to be taken into account.
More environments can always be created, but don’t expect teams to scale overnight. Many companies adopt DevOps, moving to faster, more frequent releases driven by the needs of individual projects, before realising that an increase in the frequency of software delivery can lead to QA and release management burnout.
If organisations are introducing more automation to accelerate their time to market, the impact of DevOps initiatives on the teams needs to be considered closely.
Problem #3: Having no regard for governance
A lot of the rhetoric in favour of DevOps is rooted in the idea that developers need to take a proactive approach to evade change-averse administrators.
DevOps in the enterprise often emerges from one or two groups deciding to stage a “revolution” against an ineffective IT organisation. When a company has a large system and intractable releases that take months, teams often lose patience with the process and are tempted to break the mould and move quickly.
The first teams to embrace DevOps were breaking the rules by design. They were comprised of independent teams free to innovate outside centralised IT structures. But while this approach works for smaller startups, it is not effective in many enterprises.
An organisation with dozens of independent teams creating continuous deployment pipelines may sound good in theory, but it doesn’t work so well in practice. DevOps isn’t about reducing the number of governance gates. On the contrary, DevOps enables more effective, more frequent governance gates to shine a light on complex release orchestration challenges.
Problem #4: Not taking risk into account
Many companies dive head first into DevOps without a full understanding of how it will affect risk associated with software releases.
When a company transitions from a slower, ITIL-focused process to a more agile, DevOps-focused reality, release managers are often expected to “wing it” towards the end of the release cycle. Many organisations forget to factor in risk for decisions about production. The software can be delivered faster, but the enterprise still requires governance gates.
Changes to production facing systems require rigorous change management, along with release management function to track conflicts and risk. One way to streamline the process is through continuous delivery management, which allows teams to conduct multiple simultaneous releases while integrating existing tools, that operations expect to have in place, to track and manage risk.
Problem #5: Not using metrics with your DevOps
DevOps teams often start out eagerly working to make a change to an organisation’s infrastructure and release process, but they can also bite off more than they can chew.
Even though DevOps teams may want to reinvent a release process overnight, IT managers should still define metrics to evaluate whether DevOps initiatives are a success. Managing the slow transition to DevOps tools and techniques over several quarters can be difficult while prioritising ongoing software development and release management.
It’s good practice to regularly check in with developers and system administrators, not on the team and objectively assess the results. When pulling together a DevOps team, organisations should define roles and responsibilities to bring greater efficiency. It is essential to keep track of release and environment metrics to make informed decisions about particular initiatives from the DevOps teams.
With the continued uptake of DevOps increasing, more organisations will be looking to use it for speeding up software delivery and success. By following these solutions to five common failures, they can ensure their initiatives have a higher chance of success.
