7 pitfalls that undermine DevOps success.

IT leaders seeking faster delivery of apps and services are increasingly turning to DevOps. But blending development and operations is tricky business.

Many organizations have begun incorporating DevOps into their IT mix, whether it’s for small projects or on a larger scale.

While DevOps can provide a number of benefits — faster delivery of applications and features, improved communication and collaboration among development” and operations teams, faster resolution of problems, and iterative IT service delivery — there are no guarantees of success.

As research firm Gartner has noted, “DevOps is quickly becoming mainstream, but questions remain on how this relatively new approach to culture, automation, and platform design can deliver what it promises.” Many organizations still face roadblocks implementing and scaling a DevOps practice, the firm says.

Through 2022, 75% of DevOps initiatives will fail to meet expectations due to issues related to organizational learning and change, Gartner says.

Here are some common pitfalls to avoid.

Lack of required skills

The technology skills gap can affect virtually every aspect of IT, and DevOps is no exception. If team members of the development or operations sides of DevOps don’t have the skills an organization needs, any attempts to gain benefits from DevOps will likely fail.

“It is key for team members to have both hard and soft skills,” says Sam Babic, senior vice president and chief innovation officer at content services provider Hyland.

The company employs DevOps and automation in a number of areas of the business. “These practices are leveraged within our IT organization to satisfy the operational needs of the business, such as accounting, finance, sales, marketing, etc.,” Babic says. Hyland also uses DevOps to create the software products that it delivers to its customers through various channels.

For cloud-based products that follow a continuous delivery model, “we use DevOps and automation to update the single source of software that all customers share, as well as to update any data models and other peripheral components necessary for operation,” Babic says. “This environment also leverages automation for monitoring as well.”

And the environment requires hard skills in a number of areas, including container orchestration system Kubernetes; release management applications; software provisioning, configuration management, and application deployment tools; version control tools and services such as GitHub; languages such as Python, JavaScript, Bash, and Node.js; and various security technologies.

“Being that the workloads that we manage for our customers are in the cloud, the team must be acutely aware of the cloud platforms and the cloud services that are available,” Babic says.

From a soft skills perspective, communication and collaboration are vital. “It is incumbent that [DevOps] champions communicate clearly and often in the sharing of ideas and practices,” Babic says. “In those areas where the teams operate as a shared service, they must understand the deployment considerations of the various products, and work closely with the product teams to ensure that their products align with deployment strategies early in the design stages.”

Feedback loops are important, so that automation practices are constantly improving, Babic says.

Failure to establish well-defined processes

DevOps is a process, culture, and discipline that marries development tasks with operational procedures, says Emal Ehsan, director at Cervello, a unit of global management consulting firm Kearney.

“Each organization must look at their current approaches and map out a foundational set of processes and procedures for building DevOps as a core competency, and what the impact of those changes would be,” Ehsan says. “Once that is done, take the time to build the foundational capabilities with the expectation that the extra plumbing does take planning.”

That can be an intimidating change of pace for organizations that value agile processes and early wins, Ehsan says. “But you’ll make it up with the higher quality of work that can be reiterated again and again,” he says.

The first time the process gets put together, it might take longer than expected for the first deployment. But subsequent deployments could be done in a fraction of the time, Ehsan says. The return on investment for the upfront cost will inevitably come from those subsequent iterations, he says.

“During your foundational phase, it’s also very important to define what ‘success’ means and how you will measure it,” Ehsan says. “Are you cutting down the number of application outages by 20%? Raising the percentage of successful first-try deployments for version releases by 30%? Shortening lead times to new infrastructure environments by four days?”

Defining success serves two purposes. “The first is giving you the basis to encourage further adoption,” Ehsan says. “The second is to give the team a tangible goal. If your team is competitive by nature, a high bar may drive the best results; whereas teams afraid to fail may need a lower target to build confidence and trust in both the process and their team members. In both cases, success often drives excellence beyond the target.”

Starting too big

Companies should not roll out DevOps initiatives on a grand scale, because that can overwhelm resources, including development and operations teams.

“DevOps transformations are ‘elephants’ that cannot be eaten in one bite,” Ehsan says. “Pick a starting point of focus — for example, a small project that requires input from different departments — and implement DevOps there.”

Toolsets that a company will use to achieve its goals will have varying levels of maturity, and so will the people implementing them, Ehsan says. “Cultural and technology support for your initial use cases may be in its infancy, and no matter how well planned your approach is there will inevitably come a time when you find you can’t do what you need to do the way you thought you could do it,” he says.

If a company finds itself overwhelmed by a DevOps program it was not prepared to take on, the best antidote is to make sure it has a variety of problem-solvers on the team that approach tasks from different angles, Ehsan says.

“Small wins and good collaboration become infectious, so making sure you have the right team that is flexible and able to pivot when needed will help ensure initial success and adoption of the process overall,” Ehsan says.

Providing too much or too little autonomy

One of the enduring mantras of DevOps is to give teams the autonomy to determine their own particular way of working and getting results, says

Ola Chowning, a partner at technology research and advisory firm ISG.

“The pitfall here is that too much autonomy can result in architectural sprawl, both logical as well as with tools; inability to shift team members easily between DevOps teams; and a real challenge with management oversight of organizational performance,” Chowning says.

“We’ve seen multiple examples of too much autonomy,” including a proliferation of tools, styles, and methods.

Too little autonomy, including setting up barriers that slow down work and providing suboptimal tools for a specific team need, is not good either, Chowning says.

A good practice to address the autonomy balance challenge is to create a standards body such as a center of excellence (CoE). This should be made up of practitioners across various teams, who establish guardrails around areas where standards can drive efficiency, and to help with tool selection and use, methodologies, and governance parameters.

“Set the floor of the necessary standards; things you must do, such as version control, security, privacy, etc.,” Chowning says. “Allow teams to bring needs outside of current standards to the CoE for continuous improvement” in tools, processes, and ways of working. In addition, rotate the individuals who make up the CoE, she says, allowing more team members to take part.

Assuming DevOps is a single model

When companies roll out DevOps more broadly there is often an inclination to standardize everything to simplify implementation, Chowning says. That might not be a good idea.

“Specific products/capabilities may have less or more need, or less or more capability, to support all elements of such a standard model,” Chowning says. “This may be due to architecture, business need — high rates of changes versus low — and other characteristics.”

For example, one ISG client attempted to drive both development and operational responsibility into all of its products teams using a consistent, standard model. One of the teams was working in a mainframe environment, which rarely needed changes.

When the client attempted to have the operational team take over development duties, it found that the team lacked the skills or experience to do the job. “Yet when they looked to hire the development-experienced resources, they found that the price of keeping these skills full time — when they only rarely made development changes — represented more cost than they could realize in benefit,” Chowning says.

The experience led to the recognition that this particular technology capability did not lend itself to a high degree of DevOps from a teaming perspective. “Even the automation and tooling standard was deemed inappropriate, given the architecture and the timeline of eventual replacement within just one or two years,” Chowning says.

Rather than embracing a one-size-fits-all DevOps model, ISG recommends creating “full DevOps” and “minimal DevOps” models. “From these two models, create a list of minimum requirements that apply to both models and that every team could benefit from, and these become your core DevOps practices and principles,” Chowning says. “What you end up with is essentially multiple levels of DevOps that differ effectively team to team, and even allow each team to ‘level up’ or ‘level down.’”

Neglecting to measure the impact of change

DevOps means change, and change doesn’t always go smoothly. Better to find out sooner than later if something is not working the way it should.

“If you’re doing automated testing in a new deployment pipeline, early warnings may save you from later disasters,” Ehsan says. “Unfortunately, no one notices fires that never took place or celebrates the electrician that didn’t burn the house down.”

Over time, organizations that collect metrics on the impact of DevOps will reap the benefits via the quality of the work and the satisfaction of clients, internally and externally, because things work.

In addition, it’s hard to justify time and dollars spent on DevOps without showing the impact, Ehsan says. “If you want sales teams to add lead time, you want the CFO to approve the budget, and you want to scale the exercise to the rest of your organization, you’ll need data and results to show them,” he says.

Not creating a DevOps culture

For DevOps to be highly successful, teams need to be passionate about it, and that comes from building the right culture.

“Culture is key. The team needs to be a team that wants to work in DevOps methods,” says Brian Balzer, vice president of digital technology and business transformation at bottling company G&J Pepsi.

“They have their roles, but want to work together to complete the goal,” Balzer says. “They need to have cross-discipline skills and good business knowledge. If the team members only want to work in their discipline or what their defined job description is, you will struggle.”

G&J Pepsi has been operating in the DevOps framework since 2009 and officially adopted DevOps as a defined discipline in 2018. “Because we have been a lean, small team, this way of working was not necessarily choosing to find a formal definition of how to work, but more of a necessity to deliver value to the organization, survive ever-changing technology, [and] complete projects,” Balzer says.

It has taken a lot of time to create a DevOps environment and team, including rigorous education and training. In fall of 2020 the company brought in an agile coach to assess its processes and how the team was working. “This was very valuable, and after a few months we had restructured how we organized our team,” Balzer says. The team has progressed and is now functioning smoothly in the DevOps method.

“The team has embraced this new way of operating, it’s cadences, and is now is starting to deliver,” Balzer says. “We measure our throughput, our ability to storyboard, and the value we deliver to the business. And most importantly, we are building credibility with the executive team, have drastically improved relationships with our business partners, and have increased the adoption of the products we implement across the organization.”