What to do if you have a DevOps failure (and you will)

Source – techtarget.com

DevOps offers significant promise for organizations seeking to better integrate business development with IT. When teams automate their processes and reduce the time it takes to test code and integrate improvements across platforms, they maximize efficiency. Automation does not, however, equate to automatic success. Creating a DevOps program is difficult — adoption has to be about more than the technology — and without the right plan and processes in place, there is a good chance you could have a DevOps failure.

Many failures associated with DevOps can be avoided by taking a holistic approach to the roles that people, processes and technology all play in DevOps. Consider these common examples of DevOps failure:

Assuming DevOps is exclusively a technology change. A successful DevOps program focuses on a company’s culture. Collaboration, communication and team integration are critical when undertaking an initiative as vast as the creation of a DevOps program. This means a variety of considerations — a company’s values, management styles, teamwork, workspaces, tooling, expectations, meeting styles, cycle times, work-life balance, communications, transparency and goals — must be encompassed to gain buy-in and safeguard against DevOps failure.

Assuming DevOps does not also include a technology change. DevOps requires tools that are agile and provide observable feedback loops and continual learning. As such, many organizations will require a technology change that allows for new approaches, like cloud compatibility, process automation and metrics-based monitoring.

Treating DevOps as something only involving devs and ops. DevOps does not start with devs or end with ops. It must include all stakeholders involved; otherwise, the bottlenecks that exist are just being shifted, and you could be setting yourself up for DevOps failure. It is critical to engage project management, security, database administration, network and more to get them ingrained on the key ideas of DevOps (collaboration, sharing, etc.), as well as the processes of DevOps (self-service, continuous learning, etc.)
Expecting results too soon. On average, DevOps does work (according to research conducted by DevOps Research and Assessment) — but not the first time or every time. It is important to have realistic and measurable goals for DevOps, especially in the early stages of the program.

Expecting DevOps process perfection. As with any new business endeavor, things don’t always go according to plan. When starting a DevOps program, choose low-risk areas for experimentation that have minimal impact to the most important applications. When DevOps failure does occur, recognize if it is positive failure, and learn to accommodate failure (a key variable to any innovative culture). Accept failure that is fast, small, cheap and smart, then learn from it and do not do it again. Building in “failure budgets” can help to keep expectations realistic.

Maintaining existing silos and functional teams. Adding a DevOps team to existing dev and ops teams is rightly regarded as an “anti-pattern” because it creates a new silo, rather than breaking down the silos that exist. However, carefully creating a dedicated and inclusive DevOps team is often an excellent start to gaining needed experience and skills with minimum cost and risk. So, a new DevOps team can be used as a pilot or a model, but the end goal should be DevOps for everyone across multiple product or mission teams (i.e., where one team can plan, build, ship and run their application, aligned to business services and corporate objectives).

Losing sight of what is actually happening. DevOps encourages systems thinking, but many aspects — like self-organization and process automation — can actually encourage more silos and less visibility. It is important to expose all of the delivery process to all of the stakeholders, allowing them to know what is happening across the system, and create common reporting and tooling procedures. System transparency and end-to-end visibility enables devs, ops and other application delivery stakeholders to work better as a team, deliver new capabilities sooner, ensure higher work quality, respond faster to incidents, celebrate success, learn from DevOps failure, align with the business’s goals and deliver more value from the program.

Those might sound like a lot of potential obstacles, but DevOps failure is preventable. By designing a plan that avoids these common pitfalls, organizations can experience the promises of DevOps and create a framework for maximizing organizational efficiencies. Once your DevOps program is up and running, it is important to continue to make smart investments. From software partners to technology upgrades and talent acquisition, investing in the proper infrastructure can help to ensure future success.

DevOps makes software development powerfully efficient, but it is not a turnkey solution for all organizations. DevOps integrations need to be treated like any other transformational shift. To be successful and avoid DevOps failure, your approach needs to be holistic.