Top 10 Mistakes To Avoid When Adopting DevOps

A CIO decides it’s time for their organization to adopt DevOps. They hire a team of digital unicorns, adopt an array of cutting-edge tools, and are disappointed when they don’t see results. All the ideas, projects, products, and teams being introduced are held back by increasingly outdated cultural norms, processes, infrastructure, and skills. Nothing is aligned with the new operational models and technologies being introduced, and the digital unicorns are locked behind a dam along with their potential. The business is unable to release software with the agility and velocity required to innovate and goes under.

Along the way, the organization made several mistakes that proved fatal to their DevOps adoption.

The Biggest DevOps Mistakes

1. Lacking buy-in from business, technical, or management stakeholders

DevOps requires comprehensive change throughout an organization that can involve reallocating power and influence, uprooting long-standing tools, and retiring old processes. A lack of buy-in from any stakeholder can drive a wrench through the entire operation. Opposition may come from the finance department who may not understand DevOps and its necessity, it may come from technical VPs who have become overly accustomed to managing their department a certain way, or it may come from engineers who don’t want to retrain themselves in new tools and processes. Resistance can come from anywhere, and ignoring it can be one of the biggest mistakes organizations make when trying to adopt DevOps.

2. Not thinking about culture first

DevOps adoption is 80% cultural, and culture should therefore always be treated first. While advanced tools and processes may accelerate release pipelines, the pipelines themselves are enabled by cultural generativity. The Westrum model is often used to evaluate the strength of a company culture within three classifications. Generative cultures are performance-oriented and characterized by high levels of cooperation and trust. Bureaucratic cultures are rule-oriented and preoccupied with rules and responsibilities. Pathological cultures are power-oriented, fear-based, and uncooperative. Cultural transformation is a necessary precursor to the successful adoption of DevOps tools and practices.

3. Formulating their DevOps practices around a technology stack rather than the other way around

Organizations sometimes take the perceived shortcut of choosing technology stacks that others have built and tools that others have written about. Their methodologies are biased towards what their technology stack can do, and they end up jamming their business requirements into their features. In contrast, organizations that assess and formulate their practices before choosing their tools have the opportunity to reflect on the unique problems that need to be solved. They are able to build business intelligence into their methodologies, meaning their features address the business’ needs. Technology stacks should revolve around culture and processes rather than the other way around.

4. Adopting DevOps without knowing why

DevOps is a journey, not a destination, but knowing what you hope to accomplish from adopting DevOps will streamline your journey and help you focus your efforts. Are you hoping to reduce costs by increasing efficiency, prevent a data breach by improving security with DevSecOps, or release features with more velocity? There are many different ways that DevOps could help your business, but aligning all your IT initiatives around a common goal will help you become a Cloud Center of Excellence.

5. Hiring a DevOps unicorn or DevOps team to do it all

DevOps isn’t a role that can be filled by a single individual or team. It requires changing the tools, processes, and culture being used by all teams and individuals. Focus on upskilling and retraining existing teams to embrace DevOps tools and processes across the organization instead of isolating DevOps within newly created teams.

6. Launching ‘Agile’ projects with too much red tape and backlog

Your teams can’t be agile or innovative if they have too much red tape to navigate. They can’t deliver end-to-end business value in short cycles if basic tasks require jumping through regulatory hoops, such as getting written approval from security, legal, finance, or any other department before testing assumptions. Give your teams the freedom to pivot quickly whenever needed by allowing them to be self-organized and autonomous.

7. Miscommunication between business and technical teams

Make sure technical teams don’t choose tools they find technically interesting but that don’t suit the business’ requirements, and make sure business stakeholders don’t choose tools that lack long-term technical viability. BizDevOps is all about integrating feedback from the business side of an organization into its software delivery cycles. It aligns DevOps cycles more closely with business objectives and can prevent miscommunication between teams.

8. Not considering third-party dependencies

Large organizations that have outsourced basic IT functions may find it difficult to transition toward an API-driven model. Third-parties may find it goes against their interests to help clients transition to cloud native architectures as they may spend less money and reduce their dependency. When assessing your pipelines, consider how third-party dependencies could create bottlenecks.

9. Not thinking about a long-term technology roadmap

As open source projects are likely to survive the rise and fall of various vendors, they can sustain the long-term growth and innovation required to build reliable, resilient, cost-effective, and secure cloud services at scale. However, they can be complex to build, test, manage, and upgrade. Knowing where you want your organization to be technologically in five, even ten years will help you choose open source or commercial tools that match your use case.

10. Not considering the impact on existing structures

While operations have traditionally owned the infrastructure and app developers the application, DevOps requires introducing a new application platform layer that carries an entirely new realm of responsibility between the infrastructure and application. Large enterprises with rigid structures may find this challenging, especially if they have to work around existing (and sometimes painfully obvious) obstacles and bad practices. When architecting an application platform, consider its possible impact on existing structures.

It’s 2020, and DevOps is a necessity not a luxury. When initiating your organization’s DevOps adoption, be sure to avoid making one of these common mistakes.

To learn more, download our white paper called “How to Initiate DevOps Transformation by Assessing Culture and Processes.”