If DevOps is ultimately more about culture than any particular technology or platform, then remember this: there is no finish line. DevOps is a continuous journey of change and improvement — and the C-suite does not get a pass.

Leaders who want DevOps to deliver measurable business outcomes need to revise some of their traditional approaches. Below are seven actionable rules for more effective IT leadership in the DevOps era.

1. Say “Yes” to Failure

The word “failure” has long carried very specific — and almost universally negative — connotations in IT: server failure, backup failure, hard drive failure. A healthy DevOps culture, however, depends on redefining the term entirely. IT leaders need to reframe failure as opportunity.

“Prior to DevOps, we had a culture of punishing failure. The only learning we had was to avoid mistakes. The number one way to avoid mistakes in IT is to not change anything: don’t accelerate the release schedule, don’t move to the cloud, don’t do anything differently!”

— Robert Reeves, CTO and co-founder of Datical

That kind of stasis is itself a form of failure. Organizations that release slowly and avoid modernization out of fear are not playing it safe — they are falling behind.

“IT leaders must embrace failure as an opportunity. Humans not only learn from their mistakes, they learn from others’ mistakes. A culture of openness and psychological safety fosters learning and improvement.”

— Robert Reeves

Building psychological safety — where engineers can experiment, fail fast, and share lessons openly — is one of the most impactful things a leader can do to accelerate DevOps maturity.

2. Live, Eat, and Breathe DevOps in the C-Suite

DevOps culture can grow organically, but organizations transitioning away from monolithic, siloed IT practices need unambiguous executive buy-in. Without visible leadership commitment, mixed messages will embolden those who prefer the status quo.

“Top management must fully support DevOps in order for it to be successful in delivering the benefits.”

— Derek Choy, CIO at Rainforest QA

Becoming a DevOps organization touches nearly every dimension of the business: technical teams, tooling, processes, and roles and responsibilities. Partial commitment from leadership produces partial — and often frustrating — results.

“Without unified sponsorship from top management, DevOps implementation will not be successful. It is important to have leaders aligned at the top level before transitioning to DevOps.”

— Derek Choy

3. Don’t Just Declare “DevOps” — Define It

Even in organizations that have embraced DevOps enthusiastically, a common and underestimated obstacle is definitional ambiguity. Different teams may be operating with fundamentally different interpretations of what DevOps means, leading to misaligned priorities and conflicting practices.

“DevOps can mean different things to different people. It is important for C-level and VP-level executives to define the goals of DevOps, clearly stating the expected outcome, understand how this outcome can benefit the business, and be able to measure and report on success along the way.”

— Derek Choy

Beyond an agreed definition, DevOps requires frequent, transparent communication at every level of the organization — not just within engineering teams.

“Inevitably, there will be hiccups, failures, and disruptions to the business. Leaders need to clearly communicate the journey to the rest of the company and what they can expect as part of the process.”

— Derek Choy

4. DevOps Is as Much About Business as Technology

IT leaders running successful DevOps organizations have come to treat DevOps as a business strategy, not merely an engineering methodology. DevOps culture is one of the most effective levers for shifting IT from a cost center to a strategic business driver.

“IT leaders must shift their thinking and approach from being cost/service centers to driving business outcomes. A DevOps culture helps speed up those outcomes via automation and stronger collaboration.”

— Mike Kail, CTO and co-founder at CYBRIC

“An effective IT leader will need to be more engaged with the business than ever before. Gone are the days of yearly or quarterly reviews — you need to welcome bi-weekly backlog grooming. The ability to think strategically at the year level, but interact at the sprint level, will be rewarded when business expectations are met.”

— Evan Callendar, Director of Performance Services at West Monroe Partners

Promoting smart risk-taking and innovation are not soft leadership ideals — they are operational necessities for any organization competing in a continuous-delivery world.

5. Change Anything That Hampers DevOps Goals

Declaring your department a DevOps shop while resisting necessary changes to processes or tooling is counterproductive. DevOps culture must be enabled by the right infrastructure — and that starts with automation.

“IT leadership has to put an emphasis on automation. This will be an upfront investment, but without it, DevOps will simply engulf itself with inefficiency and lack of delivery.”

— Evan Callendar

Automation is foundational, but meaningful change extends further — into monitoring strategies, continuous delivery pipelines, team structures, and role definitions.

“Leaders need to push for automation, monitoring, and a continuous delivery process. This usually means changes to many existing practices, processes, team structures, and roles. Leaders need to be willing to change anything that will hinder the team’s ability to fully automate the process.”

— Derek Choy

6. Rethink Team Structure and Performance Metrics

If your organizational chart has barely changed in a decade, it’s overdue for a serious review. Rigid team boundaries are antithetical to the cross-functional collaboration that DevOps depends on.

“IT executives need to take a completely different approach to organizational structure in this new era of DevOps culture. Remove strict team boundaries, which tend to hamper collaboration, and allow teams to be self-organizing and agile.”

— Mike Kail

The rethinking must extend to how you measure success. Vanity metrics — lines of code written, test coverage percentages, server uptime in isolation — tell you little about whether DevOps is delivering business value.

“DevOps metrics should be tied to business outcomes in some manner. You probably don’t really care about how many lines of code your developers write, whether a server had a hardware failure overnight, or how comprehensive your test coverage is. But you do care to the degree such metrics can be correlated with customers abandoning shopping carts or leaving for a competitor.”

— Gordon Haff, Red Hat technology evangelist

“Measure initiatives in terms of business outcomes and overall positive impact. And something I believe to be the most important aspect of management: be empathetic.”

— Mike Kail

7. Chuck Conventional Wisdom Out the Window

The DevOps age demands new ways of thinking about leadership — which means some longstanding approaches need to be retired. When asked which ones, the answer from practitioners is blunt.

“To be honest, all of them. Get rid of the ‘because that’s the way we’ve always done things’ mindset. The transition to a culture of DevOps is a complete paradigm shift, not a few subtle changes to the old days of Waterfall and Change Advisory Boards.”

— Mike Kail

One concrete example of outdated thinking: the preference for architecture consolidation in homogenous environments as a cost-saving strategy.

“One of the big rules I see going out the window is architecture consolidation, or the idea that long-term maintenance is cheaper if done within a homogenous environment.”

— Evan Callendar, West Monroe Partners

Modern infrastructure approaches — containers, microservices, hybrid IT — embrace heterogeneity as a feature, not a liability. Leaders who refuse to engage with these models risk constraining both their engineering teams and their competitive agility.

Summary: The DevOps Leadership Checklist

• Reframe failure as a learning opportunity and build psychological safety into your culture.
• Secure genuine C-suite alignment before launching a DevOps transformation.
• Define what DevOps means for your organization and communicate it clearly and consistently.
• Connect DevOps to business outcomes, not just engineering velocity.
• Remove process and tooling blockers, especially by investing in automation and continuous delivery.
• Restructure teams and metrics to reflect cross-functional collaboration and business-aligned KPIs.
• Discard legacy assumptions about architecture, governance, and management style.

DevOps leadership is not a destination — it is an ongoing practice of questioning assumptions, enabling your teams, and relentlessly aligning technology decisions with business value.

DevOps: Still Evolving, Still Expanding

DevOps—the practice of integrating software development and IT operations teams into a unified, collaborative workflow—has spread rapidly across organizations of all sizes. The core promise is straightforward: break down the silos between Dev and Ops so that software can be delivered faster, at lower cost, and with higher quality. Despite significant momentum, DevOps remains a discipline in flux. Its success depends not just on tooling, but on cultural alignment, process redesign, and organizational buy-in. The five trends below reflect where DevOps has been heading and why each one still deserves attention.

1. Microservices Architecture

The adoption of microservices accelerated significantly as teams looked for ways to decompose large, monolithic applications into independently deployable units. Rather than deploying a single large codebase, microservices break functionality into discrete services, each running in its own isolated environment with its own allocated compute and memory resources.

This isolation makes microservices a natural fit for DevOps workflows:

• Independent deployment: Teams can release individual services without coordinating a full application deployment.
• Targeted scaling: A single high-demand service can be scaled horizontally without scaling the entire application stack.
• Clearer ownership: Small, cross-functional teams can own specific services end-to-end, reinforcing DevOps accountability models.
• Composability: Discrete microservices can be combined to build larger, more complex systems incrementally.

Containerization platforms such as Docker and orchestration tools like Kubernetes have become tightly coupled with this trend, providing the runtime infrastructure microservices need to operate reliably at scale.

2. Tool Consolidation

The DevOps toolchain ecosystem is vast. Configuration management tools such as Chef, Puppet, Ansible, and SaltStack each offer overlapping but distinct capabilities. Add in CI/CD platforms, monitoring stacks, artifact repositories, and secrets managers, and the result is a sprawling, difficult-to-maintain toolchain.

Organizations have responded by consolidating toward a smaller set of well-integrated, “best-in-breed” tools rather than adopting every available option. This consolidation trend also drove significant M&A activity—Cisco’s acquisition of AppDynamics for approximately $3.7 billion is one frequently cited example of a major vendor expanding its DevOps and observability portfolio through acquisition.

The practical benefits of consolidation include:

• Reduced cognitive overhead for engineers managing fewer tools
• Lower licensing and maintenance costs
• Improved integration between pipeline stages
• Easier onboarding for new team members

3. Security Shifting Left (DevSecOps)

Security has historically been treated as a gate at the end of the software delivery lifecycle—reviewed by a separate team shortly before release. DevOps practices have pushed security earlier into the development process, a shift commonly called “shifting left” or, more formally, DevSecOps.

The 2017 Puppet State of DevOps Report highlighted a meaningful performance gap tied to this approach. According to that report, high-performing teams who had integrated security practices into their delivery pipeline spent approximately 50% less time remediating security issues compared to low-performing teams—a finding consistent across both the 2016 and 2017 survey years.

Practical DevSecOps patterns include:

• Static application security testing (SAST) integrated into CI pipelines
• Dependency vulnerability scanning on every build
• Infrastructure-as-code security linting (e.g., checking Terraform or Ansible playbooks for misconfigurations)
• Threat modeling during the design phase, not after deployment

4. Deeper and Broader Automation

Automation has always been a foundational DevOps principle, but the scope of what gets automated has expanded considerably. The 2017 Puppet State of DevOps Report found that high-performing organizations automated significantly more of their software delivery pipeline than low performers—spanning configuration management, testing, deployment, and even change-approval workflows.

Key areas where automation delivers outsized value in a DevOps context:

• Configuration management: Ensuring infrastructure state is defined in code and applied consistently (Ansible, Puppet, Chef).
• Testing: Running unit, integration, and end-to-end test suites automatically on every commit.
• Deployment: Eliminating manual handoffs in the release pipeline through continuous delivery pipelines.
• Approval workflows: Using policy-as-code to automate low-risk change approvals, reducing bottlenecks without sacrificing governance.

The cumulative effect is a reduction in toil—repetitive, manual work that does not scale—freeing engineers to focus on higher-value problem solving.

5. Big Data and Machine Learning in the Delivery Pipeline

Automated software delivery pipelines generate enormous volumes of data: build logs, test results, deployment events, performance metrics, error rates, and user behavior signals. Managing and extracting value from this data has become a discipline of its own.

Organizations have started applying machine learning and data analytics to this telemetry to:

• Identify patterns in build or test failures before they reach production
• Predict deployment risk based on historical change data
• Automatically surface anomalies in application performance metrics
• Generate actionable insights for decision-makers without requiring manual log analysis
• Integrate operational data with business analytics platforms for end-to-end visibility

This intersection of DevOps and data engineering is increasingly referred to as AIOps—applying AI and ML to IT operations data to enable faster, more informed responses to system events.

Looking Ahead

These five trends—microservices, tool consolidation, DevSecOps, expanded automation, and data-driven operations—reflect a consistent underlying direction: reducing friction, increasing feedback, and making software delivery a reliable, repeatable engineering discipline rather than a heroic, manual effort. Organizations that invest in these areas methodically, with an eye toward culture as much as tooling, tend to see the most durable improvements in delivery performance and operational stability.

CA Doubles Down on the Modern Software Factory

At its annual CA World 2017 conference in Las Vegas, CA Technologies used the stage to announce 20 new products and enhancements—what the company described as the largest single release in recent history. The announcements were framed around CEO Mike Gregoire’s long-running strategic vision: the Modern Software Factory, a model for building intelligent, secure, and automated software at enterprise scale.

Gregoire, who has championed the Modern Software Factory concept since joining CA roughly five years before the 2017 conference, addressed customers about the need to connect “ideas and execution”—using software to build on an organisation’s unique strengths before competitive pressures force the issue.

“We’ve long passed the point where enterprise software is used merely to drive efficiencies. The focus today is on innovating the next big shift for your company.”

Mike Gregoire, CEO, CA Technologies — CA World 2017

Key Announcement Areas

CA grouped its announcements into several capability pillars, each targeting a different layer of the software delivery lifecycle:

DevOps Automation at Scale

A new automation platform was introduced to help enterprises scale their DevOps practices using analytics-driven insights. The goal is to move beyond tool adoption and give teams the operational intelligence needed to continuously improve pipeline performance and throughput.

Microservices Management with CA Microgateway

CA announced CA Microgateway, a tool designed to deploy and manage microservices in minutes. As organisations decompose monolithic applications into smaller, independently deployable services, tooling that handles service discovery, policy enforcement, and API management at the microservice layer becomes essential. CA Microgateway was positioned to address exactly that gap.

DevSecOps: Security Built In From the Start

Several of the 20 announcements targeted the growing DevSecOps discipline—the practice of integrating security controls into development pipelines from the first commit, rather than bolting them on before release. CA’s new security products were presented as a way to improve security posture without creating friction that slows development velocity.

This reflects an industry-wide shift: traditional security gate reviews at the end of a release cycle are increasingly incompatible with high-frequency delivery models like continuous deployment. Shifting security left—earlier in the pipeline—distributes responsibility across development, security, and operations teams.

AI-Powered Mainframe Management

Despite the industry’s sustained migration toward cloud-native infrastructure, CA made a point of addressing its substantial mainframe customer base. New AI-powered tooling was announced to help mainframe operators proactively detect and resolve potential issues before they cause downtime, while also strengthening security on those platforms.

Mainframes continue to underpin critical workloads in financial services, insurance, and government sectors. Integrating AI-driven observability into mainframe operations aligns with broader AIOps trends playing out across the infrastructure management market.

The Modern Software Factory Framework

Across its announcements, CA consistently returned to the pillars of the Modern Software Factory: velocity, security, and performance. The framework positions software delivery not as an IT function, but as a core business capability—one that determines whether a company can respond to market changes faster than competitors.

“The ability to manage change, respond to new inputs or insights and pivot has never been more important. Our entire portfolio is designed around the pillars of the Modern Software Factory to increase the velocity, security and performance of the solutions and the apps that are critical to our customers’ businesses.”

Mike Gregoire, CEO, CA Technologies

Why This Matters for DevOps Teams

• Integrated toolchains: A vendor releasing 20 coordinated updates signals an effort to reduce integration overhead across the SDLC—relevant for teams managing complex tool sprawl.
• DevSecOps adoption: Security tooling designed to fit inside pipelines, rather than interrupt them, lowers the barrier to compliance for teams practicing CI/CD.
• Microservices governance: As microservice counts grow, API gateway tooling at the service level (not just the edge) becomes operationally necessary.
• Mainframe parity: AI-assisted operations for mainframes acknowledge that cloud transformation is incremental—many enterprises run hybrid estates for years during migration.

CA Technologies was subsequently acquired by Broadcom in 2018. Teams evaluating products announced at CA World 2017 should verify current product names, roadmaps, and licensing under Broadcom’s portfolio.

This insight comes from practitioners working inside government and large enterprises. One such practitioner, Lidgey (as reported by DevOps Online / devopsonline.co.uk), has worked across organisations including Monitise, IBM, and Companies House — the UK government’s executive agency and trading fund responsible for the register of companies in England and Wales. His experience offers a grounded view of how DevOps principles can take root even when the terminology doesn’t.

Culture First, Tools Second

The word that consistently surfaces in DevOps discussions is culture. As Lidgey put it directly: “DevOps is all about culture. Get the culture right, the people right, and the rest will follow.”

This isn’t a platitude. It reflects the practical reality that automation pipelines, continuous delivery workflows, and cross-functional teams all fail without the psychological safety and collaborative norms that allow people to experiment, fail fast, and learn openly. Digital transformation strategies that skip the cultural groundwork tend to end up with CI/CD tooling bolted onto dysfunctional team structures.

Making Cultural Change Concrete: The DESC Framework

Abstract calls for cultural change rarely land. Lidgey advocates for small, demonstrable steps — and recommends a structured communication approach called DESC to help teams navigate difficult conversations with stakeholders, colleagues, and leadership:

• D — Describe what happened, factually and without blame.
• E — Explain how the situation affected you or the team.
• S — Share what outcome you would like to see instead.
• C — Compromise by stating what concrete action you will take.

DESC is borrowed from assertiveness and conflict-resolution training, and it maps well onto the kinds of friction that DevOps transformations generate — missed deadlines, unclear ownership, and pressure to deliver without adequate runway. Using a structured framework removes some of the emotional charge from these conversations and keeps teams focused on outcomes rather than personalities.

How Companies House Applied This in Practice

At Companies House, the primary lever for cultural change was test automation. The organisation had historically relied on large manual testing teams, which created significant risk against delivery deadlines. As soon as one project wrapped, teams were immediately pulled onto the next — with little time for reflection or process improvement. DESC helped surface and address the longer feedback loops this created.

By investing in automated testing as the default approach — covering training for test teams, stakeholders, and business analysts — Companies House reduced its testing cycle dramatically. According to Lidgey: “We now only test for a day, instead of weeks.”

This is the kind of concrete, measurable outcome that resonates with stakeholders who remain skeptical about DevOps as a concept. You don’t need to call it DevOps. You call it “we ship faster with fewer defects.”

Talking to Stakeholders About Time and Money

Like most organisations undergoing transformation, Companies House faced the classic triad of constraints: finance, time, and team capacity. Lidgey was candid about the challenge: “The issue we face is telling stakeholders we need time and money to support our innovative platforms.”

His recommended approach for navigating this:

1. Identify the specific problem you are trying to solve — avoid vague transformation language.
2. Work on it in a focused, time-boxed way — demonstrable progress matters more than grand plans.
3. Demonstrate results — show stakeholders working software, reduced cycle times, or measurable quality improvements.
4. Solicit critical feedback — good or bad. Feedback loops are the engine of continuous improvement.

This iterative, evidence-based approach mirrors the core DevOps feedback loop. It also builds the internal credibility needed to secure ongoing investment in automation, tooling, and training.

The Technical Stack Still Matters

Focusing on culture and communication doesn’t mean deprioritising the technical work. Lidgey acknowledged there is significant technical lift involved: “There is a lot of technical stuff we need to do — automation, Jenkins, cloud, infrastructure and code.”

The learning curve — particularly for teams moving toward infrastructure-as-code and modern CI/CD pipelines — is steep. But Lidgey’s experience at Companies House suggests that investing in training and financial support for that technical upskilling pays meaningful dividends over the long term. Teams that can write and maintain automated tests, manage cloud infrastructure, and contribute to shared codebases become fundamentally more capable and autonomous.

Key Takeaways for DevOps Practitioners

• Lead with outcomes, not terminology. If “DevOps” triggers resistance in your organisation, frame the work as continuous improvement, faster delivery, or reduced defect rates.
• Use structured communication tools like DESC to manage the interpersonal friction that transformation inevitably creates.
• Start with automation where you feel the most pain — for many organisations, that’s testing. A single day of testing versus several weeks is a compelling story for any stakeholder.
• Make progress visible. Small demonstrations of working, improved systems build trust faster than slide decks about transformation strategy.
• Invest in people alongside tools. Training teams to own and extend automation is the difference between a one-time efficiency gain and a lasting capability.

Original source: DevOps Online (devopsonline.co.uk). Attribution to practitioner Lidgey, speaking about his work at Companies House.

The Core Problem: Silos in IT Organizations

Most IT departments are structured around functional silos—development, operations, support, and management each operate largely in isolation. This separation slows delivery, creates friction during incidents, and makes it harder to respond to changing business requirements. DevOps, as a philosophy, challenges this structure by encouraging these groups to work as a single, integrated unit.

According to Purushothaman, the key objectives of a DevOps adoption are clear: bring products to market faster, deliver software and security updates more reliably, and reduce the overhead created by disconnected teams. When Agile practices are combined with DevOps principles, organisations often see compounding benefits across both delivery speed and team cohesion.

What the Data Suggests About DevOps Maturity

A CA Technologies global study cited in the original interview found that advanced DevOps users reported significant gains: up to 52% increases in customer satisfaction and up to 50% improvements in employee productivity. The same research found that organisations combining DevOps with Agile practices reported better outcomes in employee recruitment and retention (cited at approximately 75%) compared to those using Agile practices alone (approximately 57%).

These figures point to a broader trend: DevOps is not purely a technical concern. The productivity and satisfaction improvements extend beyond engineering teams and affect how organisations attract and retain talent in competitive markets.

DevOps Is a Philosophy, Not a Product

One of the most persistent misconceptions about DevOps is that it is a tool or a piece of software that can simply be purchased and deployed. Purushothaman is direct on this point: you cannot buy the philosophy of DevOps. What organisations can do is adopt tools that support DevOps practices—CI/CD pipelines, infrastructure-as-code platforms, monitoring and observability solutions—but none of these replace the underlying cultural and process changes that DevOps requires.

DevOps is better understood as a continuous software development methodology that emphasises:

• Collaboration between development and operations teams throughout the software lifecycle
• Feedback loops that surface issues quickly and allow rapid course correction
• Continuous improvement as an organisational habit rather than a project milestone
• Holistic lifecycle automation covering build, test, deploy, and monitoring stages

Who Should Lead DevOps Initiatives?

Leadership ownership of DevOps is a question that many organisations struggle to answer. Traditionally, the CIO or CTO leads technology transformation, but Purushothaman notes a shift in where DevOps conversations are happening. As digital transformation has become central to business strategy, Chief Digital Officers (CDOs) and Chief Marketing Officers (CMOs) have become increasingly involved in DevOps discussions—not because they manage the engineering teams, but because faster software delivery directly affects business outcomes they are accountable for.

This shift is meaningful. When DevOps is framed primarily as an IT efficiency exercise, it can be deprioritised or misunderstood at the executive level. When it is connected to customer experience, time-to-market, and digital revenue, it gains broader organisational support.

For CIOs specifically, Purushothaman’s recommendation is clear:

“To unlock the promise of DevOps, CIOs must lead and support a cultural change within their technology management organisation. They must engender a culture of collaboration and learning and enable their people with the right tools to drive holistic life-cycle automation.”

Abhilash Purushothaman, CA Technologies

DevOps Adoption Varies Significantly by Industry

One of the most important practical insights from the interview is that DevOps maturity and adoption patterns differ substantially across business verticals. The regulatory environment, existing technology stack, organisational culture, and market pressure all shape how DevOps is implemented—and how quickly it can take hold.

High-Regulation Industries

Banking, financial services, and life sciences face stringent compliance and audit requirements. DevOps in these sectors must incorporate robust change management, audit trails, and approval workflows—often slowing the pace of adoption but not making it impossible. Continuous compliance tooling and policy-as-code practices are increasingly used to reconcile speed with regulatory obligations.

Retail, Media, and eCommerce

These sectors often face intense competitive pressure and consumer-facing feature demands. They tend to adopt DevOps more readily because the business case—faster feature delivery, reduced downtime during peak periods, rapid A/B testing—is immediately visible to stakeholders. Greenfield environments, such as SaaS startups and eCommerce platforms, are especially well-positioned to implement DevOps from the ground up without having to navigate legacy architecture or entrenched processes.

Healthcare and Transportation

These sectors face unique cultural challenges. Safety-critical systems and long-standing operational practices can make teams resistant to the speed-first mentality often associated with DevOps. However, the need to modernise software delivery—particularly as patient-facing digital services and connected transport systems expand—is driving DevOps adoption even in these traditionally conservative environments.

Tailoring Your DevOps Strategy: Practical Implications

Because business drivers, regulatory environments, and technology stacks differ so widely, there is no universal DevOps playbook. Purushothaman’s central point is that organisations must resist the temptation to copy another company’s approach wholesale. Instead, a successful DevOps strategy requires:

1. An honest assessment of current maturity — Where do your biggest bottlenecks sit today? In testing? In deployment approvals? In incident response?
2. Clear business objectives — Are you optimising for release frequency, system reliability, developer experience, or regulatory compliance? Different goals call for different toolchain and process choices.
3. A phased cultural shift — Cultural change cannot be mandated by policy alone. It requires leadership modelling, team-level experimentation, and visible recognition of collaborative behaviour.
4. Appropriate toolchain selection — Tools should serve the process, not define it. Select tooling that fits your existing architecture and team skill sets rather than adopting whatever is currently most popular.
5. Feedback mechanisms — Build explicit mechanisms—retrospectives, post-incident reviews, deployment metrics—that allow teams to learn and adjust continuously.

Key Takeaway

DevOps is a powerful approach to software delivery, but its effectiveness depends entirely on how well it is adapted to an organisation’s specific context. The organisations that see the greatest benefit are those that treat DevOps as a long-term cultural and operational transformation—not a tool purchase or a one-time project. Starting with a clear understanding of your own constraints and business goals, rather than imitating another organisation’s model, is the most reliable path to sustainable DevOps maturity.

Overview of the DevOps Tools Market

The DevOps tools market has expanded rapidly as organizations accelerate software delivery, automate infrastructure, and break down silos between development and operations teams. By the late 2010s, the vendor landscape had grown to include dozens of established enterprise players alongside fast-growing open-source-backed companies, reflecting widespread adoption across industries and geographies.

Market research published around 2017 attempted to quantify global demand for DevOps tooling across the full software delivery lifecycle — from source control and CI/CD pipelines through to monitoring, configuration management, and release orchestration. Analysts examined the market through several lenses: product maturity tiers, target industry verticals, and regional adoption patterns.

Key Vendors in the DevOps Tools Space

Research from this period identified a broad set of vendors competing across different segments of the DevOps toolchain. These included both pure-play DevOps companies and large enterprise IT vendors extending their portfolios:

• Puppet Labs – Configuration management and infrastructure automation
• Chef – Infrastructure-as-code and compliance automation
• Docker Inc. – Container runtime and developer tooling
• Red Hat – Enterprise Linux, Ansible automation, and OpenShift container platform
• Atlassian – Developer collaboration tools including Jira, Confluence, and Bitbucket
• SaltStack – Event-driven IT automation and configuration management
• CA Technologies – Enterprise release automation and value stream management
• Rackspace – Managed cloud services supporting DevOps workflows
• XebiaLabs – Release orchestration and DevOps intelligence
• VersionOne – Agile and DevOps planning and tracking
• Cisco – Network automation and infrastructure tooling
• CollabNet – Agile ALM and DevOps platform
• HP (Hewlett Packard Enterprise) – Testing, ALM, and operations tooling
• IBM – DevOps, cloud, and AI-assisted software delivery tools
• Microsoft – Azure DevOps (then Visual Studio Team Services) and GitHub ecosystem
• Spirent Communications – Network and application testing
• VMware – Virtualization and cloud infrastructure supporting DevOps pipelines
• DBmaestro – Database DevOps and release automation

This vendor mix illustrates that by 2017, DevOps tooling was no longer a niche category. Enterprise incumbents were actively competing with younger, developer-focused companies for budget and mindshare.

Product Maturity Tiers: DevOps Ready, Enabled, and Capable

One segmentation framework used in market research of this era categorized DevOps tools by the maturity level they help organizations achieve:

• DevOps Ready – Tools that support foundational practices such as version control, basic CI, and team collaboration. Organizations at this stage are beginning to formalize their delivery processes.
• DevOps Enabled – Tools that integrate across the pipeline, enabling automated testing, artifact management, and infrastructure provisioning. Teams here have consistent, repeatable delivery workflows.
• DevOps Capable – Advanced tooling supporting continuous deployment, full observability, self-healing infrastructure, and value stream management. These organizations treat software delivery as a measurable business capability.

This tiered model reflects a maturity progression that many DevOps transformation frameworks — including DORA’s research and the DevOps Research and Assessment model — also describe, though the specific labels vary by analyst firm.

Industry Verticals Driving Adoption

DevOps tool adoption has not been uniform across industries. Research segmented demand by the following verticals:

• Information Technology – The primary driver of adoption, with software companies and IT service providers leading in both tool breadth and pipeline maturity.
• Telecom – Network function virtualization and the push toward software-defined networking accelerated DevOps adoption among carriers and equipment vendors.
• Banking, Financial Services, and Insurance (BFSI) – Regulatory pressure and the rise of fintech competition pushed traditional financial institutions toward faster, more auditable release processes.
• Government and Public Sector – Adoption lagged relative to private sector but grew as digital government initiatives gained momentum and procurement rules evolved.
• Other Industries – Healthcare, retail, manufacturing, and media all showed increasing interest in DevOps practices as software became central to their operations.

Regional Market Dynamics

Geographic segmentation in DevOps tool research typically reflects the distribution of software development activity and enterprise IT investment globally:

• North America – The largest market, driven by the concentration of technology companies, cloud-native startups, and enterprise IT spending in the United States and Canada.
• Europe – Strong adoption in the UK, Germany, and the Nordic countries, shaped by GDPR compliance requirements influencing how pipelines handle data.
• Asia-Pacific – Rapid growth, particularly in India, China, Australia, and Japan, reflecting both a large developer workforce and significant cloud infrastructure investment.
• South America – Emerging adoption, led by Brazil and Argentina, with growth tied to digital transformation programs in banking and telecoms.
• Middle East and Africa – Smallest share in this period but growing, driven by government-led smart city and digital economy initiatives.

Market Forces and Growth Drivers

Analysts examining the DevOps tools market typically evaluate several categories of forces that influence adoption pace and vendor strategy:

Technology Drivers

Containerization (Docker, Kubernetes), cloud-native architectures, microservices, and infrastructure-as-code fundamentally changed what teams needed from their toolchains. Tools that integrated well with cloud providers and supported ephemeral, API-driven infrastructure gained significant traction.

Economic Drivers

Reducing time-to-market, improving developer productivity, and lowering the cost of production incidents all present measurable business cases for DevOps investment. Analyst reports in this space typically attempt to quantify these productivity gains to justify enterprise tool budgets.

Policy and Compliance Factors

Regulated industries — particularly BFSI and healthcare — increasingly required audit trails, change management integration, and automated compliance checks as part of their release processes. Vendors who addressed these requirements alongside delivery speed gained entry to otherwise conservative markets.

Market Entry Dynamics

Open-source foundations (many tools in the DevOps space started as open-source projects) lowered the barrier to entry for new vendors and for organizations evaluating tools. This created both competitive pressure on established vendors and a fragmented landscape that enterprise buyers found difficult to navigate without integration platforms or vendor consolidation.

What Has Changed Since 2017

The DevOps tools market has continued to consolidate and evolve significantly since this research was published. Notable shifts include:

• Microsoft’s acquisition of GitHub (2018) and continued investment in Azure DevOps reshaped the developer tools landscape.
• Kubernetes became the de facto container orchestration standard, anchoring a new generation of platform tooling.
• The rise of the “platform engineering” discipline prompted organizations to build internal developer platforms (IDPs) on top of tools like those listed above.
• Several vendors from the 2017 list were acquired: CA Technologies by Broadcom, XebiaLabs became part of Digital.ai, SaltStack was acquired by VMware, and CollabNet merged into Digital.ai as well.
• GitHub Actions, GitLab CI, and cloud-native CI/CD services from AWS, Google, and Azure intensified competition with standalone CI/CD vendors.

For teams evaluating DevOps tooling today, the 2017 vendor list serves as useful historical context, but the market has matured considerably. Current evaluations should prioritize integration with cloud-native ecosystems, support for platform engineering patterns, and total cost of ownership across the full toolchain.

Summary

The DevOps tools market analysis published around 2017 captured a pivotal moment when the category was transitioning from early-adopter enthusiasm to mainstream enterprise investment. The vendor landscape was diverse, spanning pure-play automation companies and large IT incumbents, with adoption spreading across IT, telecoms, financial services, and government. Understanding the structure of this market — its maturity tiers, vertical drivers, and regional dynamics — provides useful context for tracking how the DevOps toolchain has evolved into today’s platform engineering ecosystem.

1. Serverless Computing

Serverless computing is not a new concept — the underlying ideas have existed since the mid-2000s. What changed is accessibility. Modern serverless platforms such as AWS Lambda and Apache OpenWhisk dramatically lowered the barrier to entry, letting developers deploy event-driven functions without managing the underlying infrastructure. For MSPs, this means clients can reduce operational overhead and infrastructure costs. Expect serverless to become an increasingly common architecture choice for applications that demand elastic scaling and consumption-based pricing.

2. Self-Healing Infrastructure and the Push Toward NoOps

Automation has always been a foundational principle of DevOps, but maturing tooling is pushing it much further. The term NoOps describes an environment where infrastructure provisioning, scaling, and application management are so thoroughly automated that routine human intervention is no longer required. Self-healing systems can detect failures and remediate them automatically — restarting crashed containers, rerouting traffic away from unhealthy nodes, or rolling back a bad deployment without a pager alert firing at 2 a.m.

For MSPs, NoOps principles create an opportunity to deliver higher service quality at lower operational cost. The practical reality is that full NoOps remains aspirational for most organizations, but directional movement toward greater automation is well underway.

3. Shift-Left: Moving Quality, Security, and Compliance Earlier in the Pipeline

Shift-left refers to moving software delivery practices — particularly quality assurance, security reviews, and compliance checks — earlier in the development lifecycle rather than treating them as gates at the end. The metaphor comes from reading a pipeline diagram left to right: shifting activities to the left means performing them sooner.

The benefits are concrete: defects found during development cost far less to fix than those discovered after deployment. Shift-left practices include test-driven development (TDD), static code analysis integrated into CI pipelines, automated compliance policy checks, and pre-commit security scanning. For MSPs managing multiple client pipelines, embedding these checks into a shared CI/CD platform is an efficient way to deliver consistent quality across accounts.

4. DevSecOps: Integrating Security into the DevOps Workflow

In many organizations, security teams historically operated in isolation — reviewing code and infrastructure only after development work was complete. This created friction, slowed delivery, and left vulnerabilities undetected until late in the cycle. DevSecOps aims to break down that silo by treating security as a shared responsibility integrated throughout the software delivery process rather than a separate phase at the end.

Practical DevSecOps implementations include automated vulnerability scanning in CI pipelines, infrastructure-as-code security linting, secrets management tooling, and ongoing runtime threat detection. For MSPs, offering DevSecOps capabilities — or helping clients adopt them — is a meaningful differentiator as security requirements grow more stringent across regulated industries.

5. DataOps: Applying DevOps Principles to Data Pipelines

Just as security teams were initially left out of the DevOps movement, data engineering and analytics teams have often operated separately from software delivery workflows. DataOps extends DevOps principles — automation, collaboration, version control, and continuous delivery — to the data pipeline lifecycle. This means treating data ingestion, transformation, and delivery with the same rigor applied to application code: automated testing of data quality, version-controlled pipeline definitions, and monitoring of data freshness and accuracy.

Organizations that adopt DataOps can expect faster iteration on analytics products, fewer data quality incidents reaching production, and tighter alignment between data teams and the rest of engineering. MSPs with data engineering practices should evaluate how DataOps tooling and culture can be wrapped into their service offerings.

What This Means for MSPs

Each of these trends represents both a challenge and an opportunity for managed service providers. Clients will increasingly expect their MSP to have working knowledge of serverless architectures, automated remediation, shift-left pipelines, integrated security practices, and data operations. MSPs that build internal expertise in these areas — and translate that expertise into repeatable service offerings — will be better positioned to retain existing accounts and win new ones.

The common thread across all five trends is the same principle that has driven DevOps from the beginning: break down silos, automate repetitive work, and deliver faster with greater confidence. The scope of that mission is simply expanding.

But what are the right metrics for DevOps success? And which ones are actively counterproductive? This article draws on widely observed field patterns to help you distinguish useful signals from misleading noise.

Why DevOps Metrics Are Uniquely Difficult

DevOps leaders tend to struggle with metrics because DevOps entails changes that are both operational and cultural—and that span different teams and functional areas, including development, testing, and operations. Inexperience can cause leaders to adopt new metrics that are counterproductive, or—just as commonly—to continue using traditional metrics that don’t align with the cross-functional nature of DevOps objectives.

The core tension is this: many legacy metrics were designed to optimize individual output or departmental efficiency in isolation. DevOps, by contrast, is built around shared ownership, fast feedback loops, and end-to-end flow. A metric that was perfectly reasonable in a siloed waterfall environment can actively damage a DevOps culture.

Three Common Metric Pitfalls in DevOps Transitions

1. Vanity Metrics

Vanity metrics appeal to the “hero” mentality of individual contributors rather than to the collaborative process goals of cross-disciplinary DevOps and continuous delivery teams. Common examples include:

• Total lines of code produced
• Total function points created
• Number of commits per developer

When incentives are tied to these metrics, developers are nudged toward maximizing volume at the expense of equally important activities such as refactoring, design simplification, documentation, and knowledge sharing. More code is not better code, and a metric that treats it as such will quietly erode quality over time.

2. Metrics That Promote Inter-Team Conflict

Metrics that pit teams against each other undermine critical DevOps behaviors—such as code sharing, mentoring, and constructive peer reviews. A concrete example: Agile leaderboards that rank teams based on the prevention of deployments or changes can actually work against DevOps culture by discouraging teams from shipping frequently or collaborating on shared infrastructure.

While gamification can be useful in some business contexts, it requires careful design in a DevOps environment. Any competitive mechanism that rewards a team for outcomes that harm another team’s velocity or reliability is a red flag.

3. Legacy Operational Metrics Applied Without Context

Many DevOps leaders persist in using traditional metrics such as:

• Mean Time Between Failures (MTBF): Maximizing MTBF was appropriate when deployments were infrequent and risky. In a continuous delivery model, some failure is expected and even acceptable—provided Mean Time to Recovery (MTTR) is low. Optimizing purely for MTBF can actually discourage teams from deploying frequently, which is the opposite of a healthy DevOps posture.
• FTE-to-server ratios: This metric reflects a cost-reduction mindset that made sense before cloud-native architectures. As IT improves its responsiveness to the business, it must look beyond cost alone to total economic impact—including speed of feature delivery and customer outcomes.

These metrics are not inherently wrong, but applying them without adapting them to a DevOps context creates misaligned incentives that slow transformation.

What Makes a DevOps Metric Genuinely Useful?

Before committing to any metric, evaluate it against the following four criteria:

1. Obtainable

A metric provides no value if you cannot reliably capture it. Ensure your toolchain actually surfaces the data you need. In some cases, you may need to measure attributes indirectly. For example, rather than measuring employee morale directly—which is subjective and hard to quantify—you might use staff retention rates as a proxy, since that data is readily available from HR systems and correlates meaningfully with team health.

2. Reviewable

Any metric you use must withstand rigorous scrutiny in a business context. You should be able to clearly explain why it matters, what behavior it is intended to encourage, and how it connects to the stated values and mission of your team. A metric you cannot defend publicly is a liability, not an asset.

3. Incorruptible

Avoid metrics that can be easily gamed by individual team members or groups. Goodhart’s Law is especially relevant here: once a measure becomes a target, it ceases to be a good measure. Be particularly cautious about metrics that remain entrenched—despite undermining change—because bonuses or SLAs are attached to them. If a metric is creating perverse incentives, it needs to be revised or retired, regardless of how long it has been in place.

4. Actionable

Useful metrics must enable DevOps leaders to make better decisions—about workflows, incentives, policies, training, tooling, or other levers of transformation. Not every decision will be a game-changer, but incremental improvements in knowledge lead to incremental improvements in process, and those improvements compound over time. A metric that tells you something is wrong but gives you no information about what to change is an informational dead end.

A Practical Summary

Key Takeaways

• DevOps metrics must reflect cross-functional, collaborative goals—not individual heroics or departmental efficiency in isolation.
• Three recurring pitfalls are vanity metrics, metrics that create inter-team competition, and legacy operational metrics applied without adaptation.
• Before adopting any metric, test it against four criteria: is it obtainable, reviewable, incorruptible, and actionable?
• Metrics shape behavior. The wrong metrics will actively reinforce the siloed, risk-averse culture that DevOps transformation is trying to dismantle.

Choosing the right metrics is not a one-time exercise. As your DevOps maturity evolves, so should the signals you track. Periodically auditing your metric set against these criteria is itself a sign of a healthy, learning organization.

DevOps Moves from Experiment to Standard Practice

By early 2017, DevOps had crossed the line from experimental to essential. A survey of Gartner Research Circle members conducted in 2016 found that 38% of respondents were already using DevOps practices, with a further 35% planning to implement them in the following year. That meant more than 70% of the IT market was actively engaging with DevOps — a dramatic shift from just a few years earlier when it was largely confined to web-scale companies and startups.

Alongside broader adoption came a wave of venture capital investment in DevOps tooling companies, and IT budget owners began treating DevOps capability as a requirement rather than a nice-to-have. The challenge was no longer whether to adopt DevOps, but how to do it well — at scale, securely, and without accumulating technical debt in the toolchain itself.

With that backdrop, five changes were emerging that would define what mature DevOps actually looked like in practice. These themes remain highly relevant today.

Change 1: Continuous Updating Becomes the Baseline

When every company effectively becomes a software company — whether they sell retail goods, financial products, or healthcare services — the cadence of software delivery becomes a direct competitive variable. Quarterly or monthly release cycles were already too slow for many markets by 2017; the expectation had shifted to continuous or near-continuous delivery.

This pressure meant that CI/CD pipelines were no longer optional infrastructure. Teams needed to be able to merge, test, and deploy code multiple times per day without manual hand-offs causing bottlenecks. The organisations that thrived were those that treated their delivery pipeline as a product in its own right — instrumenting it, improving it, and removing friction systematically.

Key enablers of continuous updating in 2017 included:

• Automated build and test pipelines (Jenkins, Travis CI, CircleCI)
• Feature flags to decouple deployment from release
• Trunk-based development to reduce long-lived branch complexity
• Deployment automation tied to version control events

Change 2: Reliable, Language-Agnostic Tooling

Most real-world engineering organisations do not operate with a single programming language or a single technology stack. A typical enterprise in 2017 might have Java services, Python scripts, JavaScript frontends, and Go microservices all in production simultaneously. DevOps tooling that only served one language or runtime was a liability, not an asset.

The market responded by pushing platforms toward language-agnostic design — tools that could instrument, test, package, and deploy artefacts regardless of the underlying runtime. Containerisation, particularly Docker (which had gone mainstream by 2016), played a major role here: by packaging an application and its dependencies together, containers made the deployment target largely agnostic to language choice.

Beyond language support, enterprises also demanded high availability from their DevOps infrastructure itself. A pipeline that goes down takes engineering productivity with it. The expectation shifted from “reliable enough” to “highly available and clustered” — the same bar applied to production services was now applied to the tools that build and ship them.

Change 3: Hybrid Infrastructure Becomes the Default

The binary debate of “cloud versus on-premises” had largely resolved itself by 2017: most enterprises were running both, and DevOps tooling had to work seamlessly across both environments. Hybrid infrastructure models — where some workloads run in private data centres and others in public cloud — became the dominant architecture for large organisations.

This created both opportunity and complexity. On the opportunity side, teams could burst workloads to the cloud for CI test parallelism while keeping regulated data on-premises. On the complexity side, pipelines needed to handle differing network topologies, credential models, and deployment targets transparently.

Infrastructure-as-code tools — Terraform, Ansible, Chef, Puppet — gained significant traction precisely because they allowed teams to describe infrastructure intent in version-controlled files that could target multiple providers. The pipeline that provisions a staging environment in AWS could, with minor configuration changes, provision the same environment on-premises.

Change 4: Security Gets Embedded in the Pipeline (DevSecOps)

Faster release cycles create a real security risk if security checks are applied only at the end of the development cycle — or worse, only in response to incidents. The 2017 shift was a growing recognition that security scanning had to move left: into the CI pipeline, into the code review process, and into the dependency management workflow.

Three specific areas drew attention:

• Dependency vulnerabilities: Open-source libraries are the majority of most application codebases. Tools that scan dependency manifests against known vulnerability databases (such as the CVE list) became standard CI pipeline components.
• Outdated packages: Even non-vulnerable packages that are significantly out of date represent operational risk. Automated dependency update tools began to emerge as a category.
• Licence compliance: As open-source adoption grew, so did legal exposure from incompatible licences. Automated licence scanning became part of the release gate for many organisations.

This shift is now widely referred to as DevSecOps — the practice of treating security as a shared responsibility embedded throughout the software development lifecycle, rather than a gate applied by a separate security team at the end.

Change 5: Scalability Without Penalty

By 2017, many organisations were moving past proof-of-concept DevOps initiatives. Teams that had piloted a toolchain with a handful of developers now needed to roll it out across hundreds of engineers, dozens of teams, and multiple business units. The question was whether their chosen tools could scale with them — technically and commercially.

On the technical side, this meant that CI/CD servers, artefact repositories, and monitoring systems needed to handle significantly higher load. Distributed, horizontally scalable architectures for these tools became a hard requirement rather than a premium feature.

On the commercial side, organisations scrutinised vendor pricing models carefully. Tools with per-seat or per-build pricing that penalised growth created a perverse incentive: the better your DevOps practice, the higher your tooling bill. The market shifted toward pricing models that rewarded adoption rather than punishing scale.

Practically, this means evaluating DevOps tooling not just on current team size but on what the cost and operational burden looks like at 5x or 10x current scale before committing.

What These Changes Tell Us Now

Looking back from the present, all five of these 2017 predictions proved accurate — and in most cases, the trends accelerated further than the original analysis anticipated. Continuous delivery is now table stakes. Container-native, hybrid-ready toolchains are the norm. DevSecOps has become a recognised discipline with its own tooling ecosystem. And scalability is a first-order requirement in any serious DevOps platform evaluation.

If you are evaluating or evolving your DevOps practice today, these five dimensions — delivery velocity, tool reliability, infrastructure flexibility, embedded security, and scalable architecture — remain the right axes on which to assess your current state and identify gaps.

Application container adoption is on the rise, both in terms of market growth and developer interest. According to a report from 451 Research, the application container market will grow from $762 million in 2016 to $2.7 billion by 2020.

“Despite making up a relatively small portion of the overall cloud-enabling technologies market, application containers will see the fastest growth compared to other segments, with an estimated CAGR of 40% through 2020,” the report said.

When asked about the significance of these findings, Jay Lyman, a principal analyst for cloud management and containers at 451 Research, echoed statements in the report that application containers are undergoing a remarkably rapid adoption by enterprise developers. Lyman said the percentage of enterprises using application container software, such as Docker, and even system container software, like LXC, for production rivals those of disruptive technologies that have had more time to mature, such as software-defined storage and software-defined networking. The report also indicated adoption of containers is outpacing the adoption of OpenStack and other adjacent trends, such as platform as a service and DevOps.

Drivers for adoption
Lyman indicated three major drivers are pushing the rapid adoption of containers: speed, efficiency and increased use of cloud computing.

According to Lyman, reports indicated application containers have enabled enterprise development teams to move faster, not just in terms of application configuration and deployment, but also project management. He said development teams have found containers particularly useful when onboarding new developers and speeding up the time it takes to get them working on new projects.

Lyman also said the efficiency that can be achieved with containers is also making it attractive to enterprises, helping business more easily achieve the consolidation goals they have traditionally been pursuing through the use of virtual machines. He said containers offer enterprises a way to “carve up” existing server hardware in a way that is even more finite than virtual machines.

Lyman said the emergence of application container technology has benefitted from an increase in the use of cloud computing within the enterprise, something he said is still very much on the rise based on 451’s research. He added that containers have provided what enterprises have lacked thus far: a standard for packaging and deploying applications in the cloud.

“Docker emerged on the scene in the market at a time when enterprises were kind of looking for that standard way,” Lyman said. “And containers are one good way to do that. So, there is definitely synergy with cloud computing in general.”

Defining production
In terms of actual use for application production, the report found that of the roughly one quarter of enterprises using containers, 34% of respondents were in broad implementation of production applications, and 28% had begun initial implementation of production applications with containers.

Chris Tozzi, a DevOps analyst at Fixate IO, based in Livermore, Calif., said while the numbers around the adoption of application containers for use in enterprise-level production are encouraging, he would still like to see reports like this define production with “more precision.” Tozzi said he felt the report does not necessarily distinguish which percentage of organizations are using containers for small-scale internal production or large-scale, business-critical production. He added that hopes to see more developers moving beyond using containers for internal development and to move into more business-critical areas.

“What would be interesting to see is [application containers like] Docker used in massive way for production workloads, which would mean customer-facing or at least business-critical production environment,” he said.

Tozzi also said he would like to see reports like this give a more defined image of the types of applications that organizations are putting into production via containers, adding that he would like to know which percentage of production workloads overall companies are running in containers.

“That’s a big gray area,” Tozzi said. “Depending on the type of application you’re talking about, it could be really simple to fit into a container, or it could require an entire application redesign.”

While the report was unable to reveal exactly to what capacity organizations are using containers in business-critical production environments, Lyman said there is still clear indication that more organizations are moving beyond simply using containers for testing or prototyping applications.

“Through 2015 and 2016, we saw relatively rapid movement beyond … those type of proof of concepts and initial projects to actual production as well,” Lyman said.

Developers still getting comfortable
Tozzi said the report does reiterate what other reports and research has indicated in that enterprises and developers are clearly very interested in the use of containers. However, he said while developers are in fact embracing Docker, there are plenty of developers who are still in the early adoption phase.

The Compounding Effect of Agile and DevOps Together

Agile and DevOps are individually well-established approaches for improving software delivery speed and organisational responsiveness. But research into how businesses adopt these practices suggests that combining them produces compounding benefits that neither methodology delivers on its own.

A report titled Accelerating Velocity and Customer Value with Agile and DevOps found that organisations integrating both practices experienced measurably greater customer satisfaction, brand loyalty, and employee engagement compared to those using only one of the two approaches.

“What’s particularly interesting in this research is what it’s revealed about the compounded effect of using both Agile and DevOps practices, especially as it pertains to employee engagement and customer satisfaction. Agile and DevOps practices lead to happier, more productive employees — which in turn leads to happier, more satisfied customers. And when Agile and DevOps are practiced together, the benefits are even better.”

Angela Tucci, General Manager for Agile Management

Key Findings: What the Numbers Show

The report highlighted several quantified improvements for organisations that adopted both Agile and DevOps, versus those that adopted only Agile:

• Employee recruitment and retention: ~75% of combined Agile+DevOps adopters reported improvement, compared to ~30% for Agile-only organisations.
• Employee productivity: 45% increase reported by organisations using both practices.
• Customer satisfaction: 29% increase attributed to the combined approach.
• Customer experience: 78% improvement reported when Agile and DevOps were used together.

Beyond people-focused metrics, businesses also reported new business growth, increased operational efficiencies, and improved IT cost management as outcomes of joint adoption.

Why Agile and DevOps Are Mutually Dependent

One of the more striking conclusions of the research is that the two practices are not merely complementary — they are, to a significant degree, interdependent.

“Because Agile and DevOps are tightly linked around delivering value to the customer faster, we often see better success when the practices are paired. Agile needs DevOps to achieve the software delivery speed and effectiveness needed for digital business strategies, and DevOps typically isn’t successful without Agile. You can’t truly do DevOps without Agile.”

Angela Tucci

This framing reflects a widely shared view in the industry: Agile provides the iterative planning and team-level discipline, while DevOps supplies the automation, continuous integration, and delivery pipelines necessary to act on that plan at pace. Without the process rigour of Agile, DevOps tooling lacks direction; without the delivery infrastructure of DevOps, Agile iterations cannot ship at the cadence modern digital businesses require.

The Maturity Gap: Only One Third Reach Advanced Adoption

Despite the clear benefits, the report found that only approximately one third of organisations are achieving the maximum rewards from advanced Agile and DevOps adoption. The research attributes this to a significant maturity gap across the industry.

Advanced adoption is characterised by moving beyond isolated team-level practice and expanding Agile and DevOps broadly across IT — and beyond the development organisation entirely. Organisations at this level gain:

• Greater delivery velocity and release acceleration
• The ability to identify and act on new market opportunities quickly
• Consistently higher value delivered per release

The barriers preventing organisations from reaching this level of maturity include security concerns, budget constraints, skills gaps, and challenges with tooling and process standardisation.

Practical Recommendations for Scaling Agile and DevOps

The report offered three high-level recommendations for organisations aiming to realise the full benefits of combined adoption:

1. Keep the big picture in focus. Agile and DevOps initiatives should be tied to broader business outcomes, not treated as IT-only concerns. The goal is delivering the right products with the quality and predictability customers expect.
2. Measure business impact, not just delivery metrics. Tracking deployments per day or sprint velocity is useful internally, but connecting those metrics to customer satisfaction scores, revenue, and retention makes the case for continued investment.
3. Address skills gaps early. Tool and process challenges are common blockers. Building internal competency — through training, hiring, or coaching — before attempting to scale reduces the risk of stalled adoption.

“To build the right products and deliver them with the quality and predictability customers expect, enterprises must scale Agile and DevOps beyond IT. The wider benefits of fully integrating DevOps are clearly evidenced, and organisations cannot afford to ignore the important role these practices play within successful digital transformation plans. While the challenges might be wide ranging, planning and implementing a clear action plan that enables organisations to fully leverage the business benefits will soon attract returns that far outweigh the initial investment — both in terms of efficiency and cost.”

Angela Tucci

Takeaway for DevOps Teams

The central message of the research is straightforward: if your organisation has adopted DevOps tooling without Agile process discipline — or is running Agile sprints without the delivery automation DevOps provides — you are likely leaving measurable business value on the table. The compounding effect only emerges when both are practiced together, and scaled beyond the development team into the broader organisation.

For teams early in their DevOps journey, this is a useful reminder that tooling alone is not a destination. For more mature organisations, the data on advanced adoption suggests there is still significant headroom to gain — particularly in expanding practices into areas such as security (DevSecOps), finance (FinOps), and cross-functional product delivery.

A DevOps survey of 1,000 software professionals — including developers, database administrators, and managers — shed light on the real-world state of database DevOps. More than half of the companies involved employed over 500 people, giving the results reasonable weight across mid-to-large enterprise environments.

Top-Line Findings

• Within two years of the survey, 80% of companies were expected to have adopted DevOps.
• The primary driver for including the database in DevOps pipelines is increasing the speed of database change delivery.
• The biggest obstacles to DevOps adoption are a shortage of skills and a lack of alignment between development and operations teams.

Those headlines are significant on their own, but the deeper findings — particularly around the database — are where the survey becomes genuinely instructive for engineers trying to extend DevOps practices beyond application code.

Do Developers Work Across Both Databases and Applications?

The answer, consistently across all companies surveyed, is yes. Roughly 75% of developers are responsible for both database and application development. This challenges the idea that database work belongs exclusively to a dedicated DBA team — in practice, full-stack responsibility is already the norm.

The numbers go further:

• 60% of developers build database deployment scripts.
• 39% are responsible for deploying database changes to production.
• In companies that have already adopted DevOps, those figures rise to 74% building scripts and 45% handling production deployments.

The implication is clear: if you are a developer without strong database or SQL skills, closing that gap is increasingly important to your day-to-day effectiveness.

How Frequently Are Database Changes Deployed?

Deployment frequency is one of the clearest indicators of DevOps maturity, and the database is no exception.

• 44% of companies practicing database DevOps deploy database changes daily or more than once per week.
• Among companies with no plans to adopt DevOps, that figure drops to 28%.

One interpretation is that teams without DevOps simply face less pressure to release frequently. However, the answer to the next question complicates that reasoning.

What Is the Greatest Drawback of Traditional Siloed Database Development?

Survey respondents ranked the following as the top drawbacks of keeping database development separate from application development:

1. Increased risk of failed deployments or downtime when introducing database changes.
2. Slow development and release cycles.
3. Inability to respond quickly to changing business requirements.
4. Poor communication between development and operations teams.

Teams are broadly aware these problems exist. The more interesting question is what is preventing them from acting on that awareness.

What Is the Biggest Challenge in Integrating Database Changes into DevOps?

The leading challenge is synchronizing application and database changes and bridging the different working approaches of development and operations teams. This is somewhat ironic — the very problem that motivates DevOps adoption in general is also what makes extending DevOps to the database hard.

There is, however, a positive feedback loop at work. Once DevOps practices are embedded in application development, many of the coordination and communication issues begin to resolve themselves — making the extension of those practices to the database progressively easier.

How Long Will Full Database Deployment Automation Take?

This question produced arguably the most revealing result in the entire survey:

• 43% of respondents who had not yet adopted DevOps estimated it would take longer than two years to fully automate database change deployments.
• By contrast, 68% of those already practicing DevOps expected to achieve the same goal in less than one year.

Given the broad mix of industries and company sizes in the survey, this gap is not easily explained by selection bias. The more likely explanation is a compounding effect: once an organisation invests in DevOps tooling, culture, and automation for application delivery, those foundations make it substantially faster to extend the same practices to database change management.

What This Means for Your Team

The survey paints a consistent picture: the database is not an afterthought in DevOps maturity — it is a meaningful and often lagging part of the pipeline. Teams that ignore database DevOps risk accumulating exactly the bottlenecks and deployment risks they were trying to eliminate. The good news is that investment in DevOps practices generally accelerates the ability to bring the database along with it. Starting with version-controlled migration scripts, integrating database changes into CI pipelines, and establishing shared responsibility between developers and DBAs are all practical first steps.

Note: Survey data cited in this article originates from a 2017 study attributed to 126kr.com. Figures should be interpreted in their historical context; adoption rates and tooling have evolved considerably since publication.