I’ve been swimming in a sea of DevOps conversations and projects. And, to be honest, they’re all a lot of fun. I’m seeing organizations embrace their digital journey by looking much more closely at how they support users, the business, and the resources they’re delivering. A major part of this revolves around applications, code, and key services supporting the business.

Over the years, the way we’ve delivered these applications, services, and pieces of code were pretty unilateral and oftentimes manual. Today, we have a lot of fascinating development concepts specifically designed to make life easier. We have scrum, which is a great framework within which people can address complex adaptive problems. All while still productively and creatively delivering products of the highest possible value. We have agile development where requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams, bridging customers, organizations, and the end users.

And, of course, we have DevOps. Which, if you’ve seen my DevOps 101 article, you’ll now that it’s not just two words combined together. DevOps is all of the following:

On that note, I’ve worked with some folks that have said they have “DevOps teams,” but once you open up the development hood, it’s pretty clear that their definition of ‘DevOps’ is a bit off. Maybe they’ve got parts and pieces of a good DevOps process, but they’re definitely missing some pieces. And when you have a DevOps engine firing on half its cylinders, you’re just fooling yourself (and your organization) into thinking your doing a good job. That’s when business, end-users, and your applications begin to suffer.

My time working on several DevOps-related projects has opened a window into some common mistakes that organizations make when trying to deliver a true DevOps initiative. That being said, none of these are "fatal" and all can be corrected if you take a step back, see the big picture, and apply better DevOps practices. That said, my list of the top 5 mistakes organizations make while deploying DevOps:

You’re still using checklists, runbooks, or other manual processes to manage code. An absolutely massive part of DevOps is your ability to automate as much as you possibly can. This is paramount to creating a DevOps culture. This allows you to minimize human error and standardize processes across the entire software development lifecycle. Without automation, you won’t experience good, consistent, and routine code deployments. Anyone who still wants to do things ‘manually’ because they think it’ll be faster doesn’t see the big picture and certainly doesn’t understand how a good automation strategy will absolutely pay off through improved code reliability and better deployments. 

Your release cycle happens every few months (or even years) and deployments keep you awake at night. If you’re actually doing DevOps right, deployments shouldn't scare you at all. In fact, it should be a non-issue entirely. A big part of DevOps is continuous delivery practices and testing. You can do some pretty amazing things with regression testing, code validation, and much more before your code or applications even go into a production state. A good DevOps practice will have rollbacks down to a science. This allows you fix issues quickly and even respond super-fast during emergencies.

Your developers feel that their role ends at deployment. A major part of DevOps is closing the gaps between technology, business, and the end-users. If your developers stop caring once their code hits production, you’re not quite at the DevOps state. This means that developers absolutely need to be a close part of the QA process and actually care about how their code impacts what customers see.

You focus on tools over culture. Buying tools won’t get you to a state of DevOps. You could have the best tools in place and still have manual processes of working with code and operating runbooks. Worse yet, is when organizations focus too much on tools, and not at all on culture. “Implementing tools and some level of automation is the easy part,” says Adam Auerbach, VP and Co-Head of the DevTestSecOps Practice at EPAM Systems. “Getting the company culture changed to support a new way of working, blending of roles, and having time for innovation, on the other hand is going to take a lot of time and effort. But, it’s worth it. It’s key to figure out what those issues are and how to solve them; this needs to be flushed out first. This way, you unify culture to use your DevOps tools properly.” 

Your people are still in silos. If your teams don’t talk, you’re not doing DevOps. You know you’ve got it right when your developers, testers, and operations engineers are all working together. Communication and collaboration are absolutely key to actually creating a DevOps culture. Furthermore, you know you’re doing DevOps right when these same people also have business-oriented goals and values when creating code. This shows a clear unification of business and technology process.

Bridging from the previous point of involving people, operational silos can absolutely damage the way you deliver code and applications. A major part of a good DevOps culture are solid cross-functional teams. “Creating cross-functional working groups consisting of someone from, at the least, development, operations, testing, and the business,” adds Auerbach. “This will ensure that everyone has accountability to drive solutions and will help create evangelists in each group. It’s important to remember that DevOps cannot be implemented with development and operations alone.”

Sure, there are other ways you can get DevOps wrong. One of the biggest pieces of advice I can give is to never allow yourself to operate your DevOps teams with blinders on. Constantly evaluate your processes, see where you can enable more intelligence, and most of all, work together!