As Woody Allen said,
Introduction
Over the past year or so I have often been asked “why do DevOps initiatives fail?” This is such a big question that my answer has often been “it depends”, you may then say “on what?” and again the number of reasons can be just one or multiple different failure points.
Therefore I have written down here some of the reasons I have seen why organisation’s DevOps initiatives fail. These lessons are my experiences to date and I am sure there are many more different ones out there. I would also like to note an excellent post by Gartner called “The Secret of DevOps Success” where they predict that 75% of all DevOps initiatives will fail to meet expectations by 2022 – this prediction I suggest is based on many of the failures I have identified here in this article. If only we learnt from other people’s failures wouldn’t we be able to succeed? Perhaps, but every so often a new curb-ball hits an organisation that deflects the ability to totally succeed.
Before I start to discuss DevOps failures let me re-cap a little on what I believe DevOps is (also you can go to my blog DevOps – It’s an IT thing, isn’t it? for further DevOps descriptions)
- DevOps is about ‘Collaboration’ and “Co-Creation” of business outcomes;
- DevOps is about a “Continuous” way of software development and delivery;
- DevOps is Agility on steroids;
- DevOps is more than a bridge between Development and Operations – it is a Bridge across all organisational teams;
- DevOps is NOT a set of Tools.
- DevOps is much more than processes and tools, its implementation is fundamentally a culture change or even a true transformation.
As with any change, it will either be embraced by those making the change and succeed, or as Mark Twain once said “everyone… has a dark side…” with which they will reject if not understood, subverted if it does not align to personal values, or otherwise undermined and ultimately fail.
There are many clichés about “failing to define DevOps” or “failing to focus on the people side” all very good and perhaps in some cases true but do they really get to the underlining reasons for failure?
Here are some reasons I have seen with a number of organisations on DevOps failures and of course it is not exhaustive:
Culture not shifting-left
As a definition Culture within any organisation is a set of values, practices, standards, beliefs and structure that reinforce the organisational constructs and behaviour. DevOps is NOT only a set of tools, you must create a culture of DevOps and agility to get results. DevOps is a philosophy that builds upon a greater emphasis on relationships, relationships between staff, clients, peers and leaders. Failure to understand this important relationship need for people and how it impacts business processes leads to DevOps chaos. Therefore, Leaders need to set the standards for DevOps practices and behaviour by defining the desired DevOps values and behaviours needed and then aligning culture with DevOps strategy and processes.
Lack of Vision and Planning
Before starting on a DevOps path it is important to understand what DevOps means to your organisation in a consistent way – often-time individuals within an organisation believe it means something different, for instance
- Developers may define it as a specific approach to software development within a specific tool-set like Puppet, Jenkins, etc, while
- IT Management might see it as a continuation of existing processes with an emphasis on faster time-to-market
Both can be true but do not live on their own in an organisation as DevOps is much more. DevOps therefore needs to be defined consistently in line to business goals in order to increase a successful adoption. Once you have understood what DevOps means to your organisation you can take a broader perspective on things like:
- What is the existing software development process and what are the loopholes?
- What are the pain points that need to be sorted?
- How will you create a DevOps Roadmap?
- How will you train your teams (not only developers and operations)?
- What is your ultimate goal and expectations for implementing DevOps in your organisation?
Without a common understanding and definition of DevOps, teams will argue over what DevOps is and is not and why it’s being used or not. Before introducing it, organisations need to agree a consistent definition, be clear about what they are trying to accomplish and draw boundaries between DevOps and other structured approaches to IT Services Management.
Creating a “DevOps Department”
Traditional ways of business management thinking a la “Gower management practice” defines the creation of a structured independent department when setting up a new business function. Early adopters of DevOps directed themselves on this route so that it fitted within their existing organisational constructs – which is understandable.
However, by doing this they created a silo by design; DevOps enthusiast where simply jumping straight into the new way of working without taking into consideration how it impacted other connected business areas. This type of creation without removing old ways of working just ended up adding more processes and more red tape.
Your DevOps approach should be an agile and collaboration framework within which your operations and development staff begin to cooperate – not a new department. The goal is to step away from old thinking and find new ways to streamlining the end-to-end development/operations process.
Adding DevOps ways-of-working to an already over-stretched team
Understanding your existing staff workloads and their ability to execute on new ways of working and agile DevOps is critical. This means quantifying the development and operations teams’ workload and understanding individual team member’s competencies and performance. This in turn will allow you to effectively prioritise workloads and see where DevOps (including the right tool(s) for your environment) will fit in in line with your business prioritise. Even though setting up a specific DevOps department is not the best of ideas it is still essential to ensure you have the right leadership and management to manage resources (budget and talent) to make it work.
Note that a properly defined DevOps Strategy represents an ongoing learning environment that involves continuous improvement. This will require a fluid DevOps framework that must be allowed to grow, flex and change to meet the needs of the organisation. Rigidity by design in your DevOps strategy leads ultimately to DevOps failure.
Unrealistic Goals
This is obvious for everything we do - tasks, activities, projects etc and therefore it applies to DevOps. To assume that just because the idea of DevOps is so obvious that everyone will buy into it is fool-hardy of course.
One of the most striking examples of culture shock comes from when new goals are given to the development and operations teams without due regards to the organisation’s cultural ways of working (ie expecting overnight for your staff to shift from delivering releases at a pace of one per quarter to five per day simply won’t happen).
You therefore need a measured transition with small incremental steps, perhaps a “proof of solution” project to get you going. DevOps needs training, education and a breaking-in period.
Speed and Automation
Frequently organisations misunderstand the aspect of automation within DevOps – DevOps can automates the software development process with the help of continuous integration and continuous delivery (CI/CD) principles with a myriad number of tools for code repository, testing, maintenance and storage.
However, quality end-to-end DevOps still requires the power of machine-man combination for greater accuracy where you automate the mundane and repetitive NOT all the decision activities in the release cycles.
Don’t forget to apply automation across the end-to-end process which includes development, delivery and deployment. It is of utmost importance that the infrastructure set up needs a faultless strategy to plan, verify, synchronize and monitor DevOps toolchain to avoid losses.
Ignoring Governance
There is a lot of myths around the idea that developers need to take a proactive approach to evade change-averse managers. Experiences has shown that DevOps initiatives emanate in an organisation when one or two groups decide to stage cut d’état against an ineffective IT organisation – where there are large systems and inflexible releases that take months or even years, teams often lose patience with the process and are tempted to break the mold and move quickly
An organisation with many independent teams creating continuous deployment pipelines may sound good in principle, but it doesn’t work well in practice. DevOps is NOT about reducing the number of governance gates – on the contrary, it enables more effective, more frequent governance gates to highlight complex release orchestration challenges.
Ignoring the Gremlins in the Organisational systems (or failing to account for risk)
Many organisation dive head-first into DevOps without the proper due diligence on how it will affect risks associated with software releases. Although software can be delivered faster, the enterprise still requires governance gates with changes to production systems requiring rigorous change management, along with release management to track conflicts and risks.
No DevOps Metrics
DevOps teams often start out eagerly working to make change to an organization’s infrastructure and release process, but they can also bite off more than they can chew. Even though DevOps teams may want to reinvent a release process overnight, IT managers should still define metrics to evaluate whether initiatives are a success. Managing the slow transition to DevOps tools and techniques over several quarters can be difficult while prioritizing ongoing software development and release management.
It’s good practice to regularly check in with developers and system administrators not on the team and objectively assess the results. When pulling together a DevOps team, organizations should define roles and responsibilities to bring greater efficiency. It is essential to keep track of release and environment metrics to make informed decisions about particular initiatives from the DevOps teams.
Create a “hybrid DevOps Operating Model” while keeping the old traditional Operating Model intact
Creating a hybrid structure, one that applies agile methodologies while keeping IT Operations and Development teams in their traditional silos is bound to fail. This is stark in companies that have Development and Operations teams in different offices or geographies. Without combining these groups together, either physically or virtually, there is little hope of creating a collaborative environment required by DevOps.
These example “failures” are learning points that can provide some insight into some of the areas organisations need to consider when embarking on a DevOps route. Transitioning to DevOps is, first and fore-most, a cultural shift, and then a process and organizational shift.
Of all of these shifts lefts, the most critical one to take place is of course at the people level in a real way not just paying lip service to it.
Don’t just consider DevOps because of its industry hype or false promises of higher revenues and success but because of your business needs which is to essentially improve your business outcomes, be they increased profits, better customer services, better citizen engagement, etc.
DevOps takes time and effort, requires strong leadership and advocacy, and must be measured in a way that's compatible with your organization's goals, culture and ultimately your business outcomes and goals. Set yourself up for success by avoiding the mistakes that those who've come before you have already made.
Gets started with DevOps and your transformation today by visiting our HPE Pointnext Website.
Mario Devargas
WW Strategic Transformation
Hewlett Packard Enterprise
MarioDevargas
CIO Advisor, World Wide Strategic Transformation, Governance & Operations CoE -- Mario is sixty+ year-old Spaniard with English undertones – living in Preston, North West England. He has worked in the Information Technology field for over 35 years, most recently in the Public Sector as IT Director for a Northern UK Metropolitan Council and as CIO for the second largest Police Force in the UK. As a Senior Executive he majors on advising organisations on Corporate IS Strategy, Enterprise Agile, DevOps, Collaborative Shared IS services and building and leading high-performing IS teams.
