Six Reasons DevOps Projects Fail

Reality check: you can’t just flick a switch and say, “Hey, I have DevOps now.”

A DevOps transformation is incredibly difficult to make. IT leaders who hope to make the change will be required to fundamentally alter the culture of the organization and the mindset of employees while maintaining normal business output.

The truth is most first-time projects don’t pan out, and commitment is required to build a base of experience that expands over time. IT organizations switching to a DevOps operating model must be open to taking risks, and be ready to understand why things don’t work so they can turn any misses into hits the next time around.

IT’s traditional directive is “do not fail.” With DevOps, it’s “fail fast.” The difference is that under DevOps, failures can be considered experiences that allow teams to gain knowledge about the intricacies of the new technology stack; the unique workflows around those tools; the organizational makeup of the team; and potential areas of weakness in the infrastructure.

Let’s return to the story of the retailer. For its first project, the newly created DevOps team targeted host files, a heavily-used, production-required element within the infrastructure. Unfortunately, the pervasive nature of host files made it difficult to pull them under the control of the new initiative. Plus, shoehorning a widely-used component of their infrastructure didn’t work and frustrated the team.

The whole thing crashed and burned.

Undeterred, the DevOps team began another business-critical project: building an end-to-end server that would run payment store processors virtually, rather than at each store location.

This time, the project was a success. The team completed it in four weeks, building each of the 200 servers in four hours, in a fully-automated, repeatable fashion, using an older Microsoft platform. Under the old process, it would have taken 18 hours at each location and nearly five months to complete.

While smaller in scope and self-contained, the project was a visible, important app and defined how the retailer started on the DevOps journey. Failure is a part of the process; but that said, here are six common mistakes that can cause the wholesale failure of a DevOps transformation.

Mistake 1: Working in silos
IT leaders must redefine the operating model with everyone working and thinking on a horizontal plane, rather than in the vertical silos of traditional IT. Operations, business, and engineering teams should be working in lock-step. If they aren’t, then it’s not DevOps.

Don’t go out and buy products and tools without bringing everyone into the loop. Take the time to understand what business and development teams truly need. For example, sometimes business units and development teams become frustrated with the infrastructure team’s inability to support an agile environment, so they break off and start using Amazon as a proxy, building their own shadow IT using the agile model.

But if applications are mission critical, infrastructure must be part of that group, or else it’s a recipe for disaster when it comes to support, security, recoverability, or data integration.

Mistake 2: Picking the wrong projects to work on
You need some wins to get momentum going. Generally, it’s a bad idea to touch ERP and large enterprise software packages that run the core of your business. At the same time, don’t invest in an app that’s only used by a few people for non-critical purposes—it’s not a great return on investment. The best candidates for DevOps projects will accelerate time-to-market for applications that can increase a company’s competitive advantage.

Mistake 3: Outsourcing the DevOps team
Using consultants and advisors makes sense to provide expert guidance, but a DevOps team should be internal. The outsourcing model is a challenge given the imperative for continuous delivery of applications.

Mistake 4: Tying change to an individual
It may be easier to create process or confidence around an individual in the DevOps transformation. But that person is not going to be around forever.

Mistake 5: Not investing in the right tools
There are great products out there, and they are there for a reason. IT organizations that have tried to custom-adjust current tools to meet DevOps practices have a failure rate of at least 80%—and that number is probably on the low side.

Mistake 6: Forgetting to focus on process
No matter how great the automation software is, if all teams aren’t brought into the decision-making process from the outset, it merely leads to really bad processes running a little faster.

In short, without commitment from the entire company, DevOps will never stick, and the team will become siloed over time. The only difference is that now IT is in a middleman role that eliminates any added value it provided in the first place.