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.
