DevOps encompasses a set of practices that automate and streamline processes between software development and IT operations teams, enabling organizations to build, test, and release software faster and more reliably. That is the goal, anyway. But what happens when a DevOps initiative fails to meet its anticipated objectives — or, worse, actively makes software delivery harder?
The warning signs are often unmistakable. “Easy to spot warning signs include the team being constantly stressed about deployments, bugs only appearing in production, the team being scared to change code because of how critical it is, and finger pointing when collaboration breaks down,” said Brian White, senior solutions architect at Small Footprint.
“If you start to notice that your system, processes or workflow on technical teams seems to be increasing in complexity, this is an early warning sign that your DevOps initiatives are failing,” added Collin Meadows, VP of engineering and technology at Terbium Labs. “If engineers are having more trouble deploying code, making updates, spinning up servers or any other engineering task due to your DevOps practices, then it is time to revisit what those practices were put in place for and how to change them to make things less complex.”
When those signals appear, the answer is not to abandon the initiative — it is to diagnose and fix it systematically. The following five steps provide a practical framework for doing exactly that.
Step 1: Get to the Heart of the Problem
Most faltering DevOps initiatives have one or more deeply rooted problems, typically tied to a specific technology gap, a missing skill set, or a misaligned team structure. Before reaching for a new tool or reshuffling personnel, set aside dedicated time to evaluate what is not working and why.
Ensure that every stakeholder shares the same vision, goals, and success criteria. “Find people that can work alongside the team, helping and at the same time training the team to be self-sufficient,” White advised.
Scope is another common culprit. Teams can feel overwhelmed when a DevOps rollout is treated as a single, all-encompassing project. “It’s important for IT leaders not to approach application development as monolithic projects. Rather they should be broken down into smaller microservices that can be maintained by a single DevOps team,” observed Jasper van der Hoek, enterprise architect at Mendix. Breaking work into smaller, independently deployable units reduces risk and makes progress visible faster.
Step 2: Resolve Internal Dissension
Some DevOps initiatives fail not because of technical shortcomings but because the organization cannot achieve internal alignment. “People hate change, whether it’s due to fear, uncertainty, doubt, inherency or accretion,” noted Robert Reeves, co-founder and CTO of Datical. When change is forced on teams rather than developed collaboratively, it breeds resistance instead of momentum.
Addressing dissension requires a deliberate focus on culture. Van der Hoek recommended working closely with each team to enable them across all their initiatives. “This will allow them to own the processes and products that they work on, making them more willing to focus on both the development and operations side of the process.” Ownership converts reluctant participants into invested contributors.
Practical actions that help build alignment include:
- Holding open retrospectives where team members can voice concerns without blame.
- Giving teams agency over how new practices are adopted, not just whether they are adopted.
- Celebrating small wins publicly to demonstrate that the initiative is making real progress.
Step 3: Check the Metrics
You cannot improve what you do not measure. Track and visualize every part of the initiative that is capable of producing a meaningful signal — deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate are well-established starting points.
“This will allow you to see which part of the DevOps effort is deviating; then take extra precautions to help nudge it back on track,” explained Davy Hua, head of DevOps at ShiftLeft. He cautioned that throwing more resources at a failing initiative without reliable objectives and key results (OKRs) — and a clear understanding of what is failing and why — is a common and costly mistake.
When reviewing metrics, look for divergence between leading indicators (pipeline pass rates, test coverage trends) and lagging indicators (incident frequency, customer-reported defects). A gap between the two often pinpoints where the breakdown is occurring.
Step 4: Restate the Initiative
When momentum stalls, teams lose sight of why the transformation matters in the first place. Clearly restating the purpose of the initiative — with concrete business outcomes, not just technical goals — can re-energize a demoralized team.
“Everyone needs to have a clear line of sight to ‘why’ DevOps will make the company better and how,” observed Rashad Neloms, VP of technology and strategy at Forty8Fifty Labs. “Get people to invest back into that first, then they can begin to see how to contribute to the success and point out where to gain more traction both process- and business-wise.”
A restatement session works best when it is cross-functional. Bring together engineering, operations, product management, and business stakeholders so that the “why” reflects organizational priorities, not just the preferences of a single department. Connecting DevOps outcomes — faster releases, fewer incidents, reduced toil — to business metrics like revenue velocity or customer satisfaction makes the case concrete.
Step 5: Assert Leadership
Lack of effective leadership is one of the most frequently cited reasons DevOps transformations underdeliver. “When DevOps initiatives fail to live up to expectations, it’s typically because business and technology leadership doesn’t have the trust in their teams to deliver quality software and allow automation to do its job,” noted Ed Price, director of compliance at Devbridge Group.
Effective DevOps leadership is cross-functional by nature. “You need a leader who is able to work with people cross-functionally,” added Antony Edwards, CTO of Eggplant. Defining clear, agreed-upon objectives is equally critical. “If there is no clear, agreed goal, then you’ll never get people to agree what to do.”
Importantly, leadership cannot be confined to the top of the organizational chart. “There should be champions in each team that will push the effort along some of the most difficult and painful transformational periods,” ShiftLeft’s Hua explained. Embedding advocates at the team level ensures that the initiative has energy and accountability at every layer of the organization, not just during executive presentations.
Putting It All Together
A DevOps initiative that is struggling is not necessarily a failed one. The five steps above — diagnosing root causes, resolving internal conflict, measuring what matters, restating the purpose, and reinforcing leadership at every level — form a repeatable recovery playbook. None of them require a complete restart; most can be applied incrementally while the team continues to deliver.
The underlying principle connecting all five steps is the same: DevOps is as much a cultural and organizational discipline as it is a technical one. Tooling improvements mean little if the team is misaligned, unmeasured, or unsupported. Address the human and process dimensions first, and the technical improvements will stick.
Original source: informationweek.com (June 2018). Quotes attributed to practitioners in the original article have been preserved as cited.