Implementing DevOps - Top 6 Mistakes

Everyone loves to talk about DevOps, but when it comes to real life enterprise implementation, things start to get a little shaky. Having gone through the process with hundreds of organizations, the XebiaLabs Sale Engineering Team relayed to me the 6 most common mistakes they see when enterprises implement DevOps for the first time. Change is never easy, but if you can dodge these top 6 mistakes, your transition to DevOps can be far smoother.

---

Not getting buy-in early in the implementation

 Go to the person that “owns the box” on the Production (aka “Ops”) side.  Talk about your initiative, and help him/her understand how this will benefit the Operational teams.  (goal:  one-button deployments in PROD)  Be willing to partner closely with this person, providing updates (demos, training) for the Operations teams.

Not having a transition plan  

Once you have some of your releases automated in this new “DevOps” way, Operations is forced to have two different deployment processes:  the new modern “automated” way, and the 17-page deployment spreadsheet.   As you start to have success in Production, it’s important to talk and plan how to bridge your DEV teams delivery models.

Not Automating 2-3 apps from DEV to PROD First 

This will help you discover all of the… “nuances” of your application delivery process.  Which people are involved, what requirements do you have, etc.  You may already know this, but automation forces companies to think about how these things will change for the better.

Only automating in the lower environments  

Most Development organizations can implement automation in their DEV and Integration environments.  But getting to environments like QA, Stage, Pre-PROD and PROD require a lot more thought about the implications of automation.   If a DevOps team is not empowered to make changes along the entire delivery path, then you will find your DevOps initiative fizzle out in this “half-auto” mode.

Creation of a DevOps team outside the existing Ops and Dev teams

One trap people fall into is introducing yet another silo.  The intention is good, a “painless” migration for certain projects, but in practice it becomes too easy to circumvent this team. Or worse, some people will exploit a fast route through this team to avoid good practices that exist in the other teams. I have seen teams avoid this trap by embedding “Ops” into the development scrums.  This system is often resisted ("too busy cutting trees to sharpen my axe”), but those who manage it learn a lot and see faster progress towards a working DevOps organization.

Focusing on the wrong thing

The main difference between doing DevOps right and otherwise is how the people interact with each other.  Shared knowledge, common goals, and desire to succeed are all traits of organizations wanting to do it right. But shared vision and overall buy-in are harder to achieve when you have more people and more heavy-weight business structure involved. Lots of things have to change in a large organization to make DevOps work, and if teams are not careful, some of those changes will disrupt other areas of the business, possibly for the worse! Organizations that focus on the people aspect of DevOps – and not just the process changes – will see greater overall success.   Hopefully our hands-on experience has allowed you to learn from others' mistakes and help you make a smooth transition into this enterprise-changing methodology.  XebiaLabs develops enterprise-scale Continuous Delivery and DevOps software, providing companies with the visibility, automation and control to deliver software faster and with less risk. Learn how…