DevOps Capabilities, Practices, and Challenges: Insights from a Case Study

DevOps is a set of principles and practices to improve collaboration between development and IT Operations. Against the backdrop of the growing adoption of DevOps in a variety of software development domains, this paper describes empirical research into factors influencing its implementation. It presents findings of an in-depth exploratory case study that explored DevOps implementation in a New Zealand product development organisation. The study involved interviewing six experienced software engineers who continuously monitored and reflected on the gradual implementation of DevOps principles and practices. For this case study the use of DevOps practices led to significant benefits, including increase in deployment frequency from about 30 releases a month to an average of 120 releases per month, as well as improved natural communication and collaboration between IT development and operations personnel. We found that the support of a number of technological enablers, such as implementing an automation pipeline and cross functional organisational structures, were critical to delivering the expected benefits of DevOps.

💡 Research Summary

This paper presents an in‑depth exploratory case study of DevOps adoption in a New Zealand‑based software company operating in the finance and insurance sector. The organization delivers a cloud‑based SaaS product suite to small and medium‑sized businesses worldwide and had been experiencing rapid growth. Prior to DevOps, development and operations were siloed: a platform team owned production systems while a product team focused on feature development. The legacy monolithic application ran in a traditional data centre, limiting scalability, availability, and deployment speed.

To remain agile and competitive, the company embarked on a multi‑year transformation that included migrating to a public‑cloud provider, refactoring large parts of the monolith for cloud deployment, and reorganising teams around an “embedded Ops” model. Platform engineers were moved into product teams, creating cross‑functional, self‑organising squads responsible for the entire product lifecycle—from code development through infrastructure provisioning, deployment, monitoring, and incident recovery. Centralised platform services (security, data services, shared components) were retained as internal service providers.

The research employed a case‑study methodology, conducting six semi‑structured interviews over six months with key participants: a developer, tester, release quality lead, team‑lead infrastructure, training manager, and operations manager. Interviews were transcribed, coded, and analysed using NVivo, guided by the DevOps framework proposed by Smeds et al. (2020). The authors extended this framework by adding metric automation as both a technological enabler and a cultural driver, arguing that continuous measurement and feedback are essential for DevOps evolution.

Findings are organised around four themes: (1) the meaning of DevOps within the organisation, (2) drivers for adoption, (3) technological and capability enablers, (4) realised benefits, and (5) challenges.

1. Meaning of DevOps – Participants described DevOps as a journey rather than a binary state, emphasizing a cultural shift toward “team control” and shared ownership of both code and infrastructure. The term “embedded Ops” captured the practice of having dedicated operations specialists embedded in product squads. Developers highlighted the freedom to choose tooling and the responsibility for cost and performance that comes with managing their own environments.

2. Drivers – The primary motivations were the need for faster time‑to‑market, higher deployment frequency, and improved reliability. The existing monolithic architecture and siloed processes were seen as impediments to scaling the business. Aligning DevOps with the company’s Agile and Scrum practices reinforced the strategic imperative.

3. Technological and Capability Enablers – Automation emerged as the cornerstone: build automation, test automation, deployment automation, monitoring automation, recovery automation, infrastructure‑as‑code, configuration management, and metrics automation. These enabled continuous integration, continuous delivery, continuous deployment, infrastructure monitoring, user‑behavior monitoring, and rapid service‑failure recovery. The cross‑functional team structure and the cultural emphasis on collaboration, shared goals, experimentation, learning, and collective ownership were equally critical.

4. Benefits – Quantitatively, deployment frequency increased from roughly 30 releases per month to an average of 120 releases per month—a four‑fold rise. This higher cadence reduced lead time for customer‑facing features, improved responsiveness to market demands, and increased overall product quality. Qualitatively, the closer collaboration between developers and operations fostered natural communication, better shared understanding of system behaviour, and a reduction in production incidents due to automated monitoring and rapid recovery mechanisms.

5. Challenges – The transition was not without friction. Migrating the legacy monolith to a cloud‑native architecture incurred significant cost and technical complexity. Introducing new automation tools required steep learning curves and integration effort with existing systems. Not all squads had fully adopted the embedded Ops model, leading to uneven operational knowledge across teams. Defining and automating meaningful metrics proved difficult; without context‑specific KPIs, the feedback loop was less effective. Additionally, re‑defining responsibilities and authority structures created temporary tension between former platform and product teams.

The authors conclude that successful DevOps adoption hinges on a balanced combination of technological automation, capability development, and cultural transformation. Merely implementing tools is insufficient; organisations must redesign team structures, embed operational expertise within development squads, and establish continuous measurement practices that align with business goals. The case study provides a practical roadmap and highlights potential pitfalls for other organisations embarking on a DevOps journey.