For decades, the development and operations teams within companies were siloed. Developers created the software. Operations tested and deployed it. But in 2009, IT consultant Patrick Debois coined the term “DevOps,” a merging of development and operations to improve communications, establish best practices and create feedback loops for organizations to keep improving the overall process.
DevOps promised to profoundly refocus and reenergize software teams, while containers looked like an interesting new way to repackage resources that were already there. However, container adoption is accelerating—and the technology that orchestrates container usage, Kubernetes, is regularly being described as revolutionary. DevOps? Up to three quarters of all organizations use a DevOps blueprint today. However, only 11% of all respondents to a recent survey by Garden are completely happy with their development setups and workflows, and think they’re operating as well as they could be. And in a DevOps Institute report, more than 50% described their DevOps transformation journeys as “very difficult.”
What is driving this disillusionment? Is DevOps a good idea on paper, but ineffective in practice? Is the process of automating tasks costing teams the time they could be using for creative innovation?
One reason for DevOps growing pains is our tendency to overestimate its role. We overestimate when we don’t fully understand something’s purpose and capabilities. And it makes sense that we overestimate DevOps – it’s loosely defined. There are thousands of organizations implementing DevOps, but no two define its role the exact same way. Before writing DevOps off, teams should clearly define what it means for their organization, reset their expectations, and develop a realistic game plan. There are three key themes to keep in mind as you define what DevOps can do for you.
Sustained culture shift
Humans have a natural resistance to change. One of the biggest roadblocks to implementing effective DevOps is the cultural shift, including skills shortages and limited-to-no automation. While leaders may express excitement at the launch of a DevOps initiative, it’s the sustained engagement that will drive long-term effectiveness. For the Puppet 2021 State of DevOps Report, organizations self-reported where they are on their DevOps journey – from low- or mid-evolution to highly evolved. “Challenges related to culture are most acute among low-evolution organizations, but present persistent blockers among mid-evolution firms. Eighteen percent of high-evolution respondents report they have no cultural blockers,” according to the report.
If managers aren’t committed to a DevOps initiative, team members can lose focus, leading to diminished effectiveness for the project overall. And if that doesn’t work, sometimes getting beat to market by a competitor is an effective way to make us realize that we must evolve to remain competitive.
Ongoing, not an end state
Departments are often measured by their progress against annual goals. For some, implementing a DevOps model might be one of those. However, DevOps is not an end state nor does implementing DevOps mean 100% adoption of integrated and automated strategies. For example, you wouldn’t want someone to do open heart surgery with software that has only been through a two-week cycle of development and testing. Some projects are better suited to a more traditional model. Maintaining both modalities – DevOps and traditional development – enables teams to benefit from both.
There is no finish line. Rather, DevOps is another tool in our toolbox – just like agile, SecOps and continuous delivery.
Creating over compliance
According to Garden research, U.S. companies are spending an estimated $61 billion a year on tasks many developers consider frustrating – like waiting for pipelines to run, waiting for builds and tests, and setting up, maintaining and debugging pipelines/automation – instead of innovation. Another common frustration is the task of achieving and maintaining detailed compliance requirements. While there is a shared responsibility between the DevOps team (who executes backups) and the Platform Ops team (who enables the backup to take place), Platform Ops teams are ultimately the ones who are responsible for compliance. Yes, DevOps is part of that process, but its core focus should be on creating, rather than compliance.
People think that the “shift left” practice means people on the left take full responsibility, but that conflicts with successful DevOps. To live up to expectations, DevOps must prioritize the actual creation of the digital service.
Organizations can reach the productivity DevOps promises by clearly defining realistic expectations. While this has been challenging in a remote work environment, I’m hopeful that as we prepare to return to the office in some capacity, there will be more opportunities for ad hoc collaboration that will catalyze excitement about DevOps – both among developers and organizational leadership.
