The pace of change in DevOps tooling and practices rarely slows down, and entering 2019 that remained true. Building on shifts seen in 2018, several key themes emerged for software delivery teams: a sharper focus on the customer, broader adoption of AI and machine learning, disciplined resilience engineering through mean time to recovery (MTTR), and a renewed emphasis on the people behind the pipelines. This article explores each of those trends and why they matter for DevOps practitioners. (Original analysis sourced from JAXenter.)
Concentrating on the Customer
One of the clearest organisational shifts entering 2019 was the move toward explicitly customer-centric value stream management. Rather than measuring success purely by deployment frequency or lead time, teams were increasingly asked to identify which steps in their delivery pipeline actually delivered value to end users — and which were pure overhead.
This requires a deliberate self-assessment. Teams need to map the full value stream, from idea intake through production, and honestly categorise each step:
- Value-adding steps — activities the customer would willingly pay for, such as feature development and performance optimisation.
- Necessary non-value-adding steps — compliance checks, security scans, and audit trails that don’t delight customers but are unavoidable.
- Pure waste — manual handoffs, waiting queues, redundant approvals, and rework caused by defects caught late.
The competitive pressure is real: as organisations work faster, customer expectations rise in tandem. Teams that cannot articulate where they add value — and demonstrate continuous improvement against that baseline — risk falling behind competitors who can.
Taking Advantage of AI and Predictive Analytics
Machine learning and AI moved from experimental to practical in software delivery pipelines around this period. The key mindset shift was reframing AI’s role: rather than seeing automation primarily as a tool for cutting headcount or eliminating waste, high-performing teams began viewing it as a mechanism for increasing value creation.
That framing matters because it changes what you measure. If AI is about reducing waste, you optimise for cost reduction. If AI is about increasing value, you optimise for outcomes: faster customer feedback, higher release quality, and shorter cycle times.
Predictive Analytics in the Delivery Pipeline
A practical application of this approach is using predictive analytics to simulate the delivery pipeline before making real changes. Instead of experimenting on a live pipeline — potentially disrupting teams and customers — organisations can model the effect of proposed changes against historical data:
- Simulate the impact of adding a new automated test stage on overall cycle time.
- Model how shifting code review earlier in the pipeline affects defect escape rates.
- Predict capacity bottlenecks before they appear under increased load.
The practical benefit is safer, faster continuous improvement: teams can learn from virtual experiments before committing to real organisational changes. Progressive organisations that adopt simulation-driven improvement loops can iterate more quickly and with less disruption than those relying solely on retrospective analysis.
Making the Most of MTTR
Mean Time to Recovery (MTTR) is one of the four key metrics highlighted in the DORA State of DevOps research, alongside deployment frequency, lead time for changes, and change failure rate. Yet MTTR often receives less attention than the others — until a high-profile outage makes recovery time painfully visible.
The business reality is straightforward: users are more forgiving of brief, frequent interruptions than they are of a single prolonged outage. A service that goes down for less than a second five times in a day is far less damaging than a service that goes down once for an hour. Customers remember downtime duration, not downtime frequency.
Practical Strategies for Reducing MTTR
- Failure planning at every layer — Design redundancy into the application delivery stack from load balancers through to databases. Assume any component can fail and plan accordingly.
- Chaos engineering — Deliberately inject failures into non-production (and, carefully, production) environments to surface hidden dependencies and test recovery procedures. Netflix’s Simian Army toolset is one of the better-known open-source examples of this approach.
- Continuous deployment with automated testing — Smaller, more frequent releases reduce the blast radius of any single deployment. Comprehensive automated test suites ensure patches are less likely to introduce new failures.
- Runbook automation — Pre-authored, tested recovery runbooks reduce the cognitive load on on-call engineers during an incident and shrink the time from detection to restoration.
Incorporating failure planning into service design — rather than treating it as an afterthought — is what separates organisations with consistently low MTTR from those that scramble during every incident.
Prioritising Your People
The fourth major theme entering 2019 was a shift in emphasis from tooling to the people and processes that surround it. The DevOps toolchain had matured significantly: containerisation, CI/CD pipelines, infrastructure-as-code, and observability platforms were widely available. The differentiator was no longer which tools an organisation had adopted, but how well their teams could use, maintain, and improve them.
This shift has a few practical implications:
- Up-levelling skills continuously — As tooling evolves, the skills required to use it effectively also evolve. Organisations that invest in training and knowledge-sharing build compounding returns; those that don’t accumulate skills debt alongside technical debt.
- Post-implementation ownership — Purchasing and deploying a tool is straightforward. Extracting sustained value from it — tuning it, integrating it with adjacent systems, and evolving its configuration as the organisation changes — requires dedicated ownership.
- Demonstrating value clearly — Engineering teams increasingly need to communicate the business impact of their delivery pipeline improvements in terms that non-technical stakeholders understand. Metrics like MTTR, deployment frequency, and change failure rate provide that language.
The Bigger Picture
The trends visible at the start of 2019 reflect a maturation of DevOps as a discipline. The early years were dominated by tooling adoption — getting CI/CD pipelines in place, moving to containers, adopting cloud infrastructure. By 2019, the conversation had shifted toward outcomes: how do these tools and practices actually improve the experience for the customer, the reliability of the service, and the effectiveness of the team?
AI and predictive analytics added a new capability layer to that conversation: the ability to model and simulate improvements before implementing them. MTTR brought resilience engineering front and centre. Customer focus and people investment provided the strategic framing that connected tooling decisions to business outcomes.
These themes have only grown in relevance in the years since. Teams building DevOps practices today will find that the foundations laid by focusing on these four areas remain sound regardless of which specific tools or platforms are in use.