People set Agile and DevOps against each other a lot, but they cover different ground. Agile deals with how a team plans and builds software in short iterations. DevOps takes the same work further, through release, operation and monitoring, and leans on automation and shared ownership to do it.
A team with unclear priorities should start with Agile. One whose finished code sits waiting on a manual release needs DevOps first.
They also fit together fine. A Scrum backlog or Kanban board produces small changes, and a continuous integration pipeline carries them out the door.
One thing worth knowing before the details. DORA, the research program behind the standard delivery metrics, renamed its annual report in 2025, so what used to be Accelerate State of DevOps is now State of AI-assisted Software Development. Since the 2024 report it has also tracked five metrics instead of four (dora.dev), which means any guide still listing four is out of date.
What is the difference between Agile and DevOps?
Scope separates them. Agile covers how teams plan and build software in short iterations, and DevOps covers what happens once the software is finished, meaning how it gets released, run and monitored. Neither one replaces the other.
| Aspect | Agile | DevOps |
|---|---|---|
| Primary focus | Planning and building working software | Releasing, running and improving it |
| Lifecycle scope | Idea to completed code | Code commit to production and back |
| Cadence | Fixed sprints, one month or less in Scrum | Continuous integration and deployment |
| Team makeup | Developers, testers, product owner | Development, operations and security |
| Feedback source | Customers and stakeholders, per iteration | Production monitoring and deployment results |
| Typical measures | Velocity, burndown | Deployment frequency, lead time, failure rates |
Atlassian puts the gap down to scope. Agile’s flow of work stops at finished code, while DevOps stretches it through delivery and maintenance.
The same source adds a second difference. Agile structures planned work for developers, and DevOps also absorbs the unplanned work operations teams handle every day.
On a mixed team that second gap causes most of the friction, because a sprint plan has no room for a production incident at 2 a.m.
Both approaches draw on lean software development, which is why continuous improvement shows up in each. DevOps also grew straight out of Agile practice.
How Agile organizes planning and development work
A cross-functional team plans and builds a small piece of working software, reviews it, and adjusts the plan based on what comes back. Then the loop repeats in another short iteration. The approach comes from the Agile Manifesto and runs through frameworks like Scrum and Kanban, plus Extreme Programming.
Agile Manifesto and its principles
The Manifesto for Agile Software Development was signed by seventeen software practitioners who met at the Snowbird ski resort in Utah from February 11 to 13, 2001 (agilemanifesto.org). It holds 4 values and 12 principles.
The values put people and interactions ahead of process and tooling, and working software ahead of exhaustive documentation. Customer collaboration gets priority over contract terms, and responding to change over following a plan.
Atlassian points out that the 12 principles already nod to DevOps ideas.
Scrum, Kanban and other frameworks
Sprints are the unit of work in Scrum. The Scrum framework fixes each sprint at one month or less and expects a usable increment at the end, per the 2020 Scrum Guide.
The Kanban method drops fixed sprints altogether. Teams show work on a board and cap how many items can sit in progress, so work flows continuously.
Extreme Programming brings engineering practices such as test-driven development and pair programming, along with frequent integration. SAFe, the Scaled Agile Framework, adds coordination for the case where many teams build one product.
Roles and ceremonies
The 2020 Scrum Guide calls the people on a team accountabilities, not roles, and describes one Scrum Team of ten or fewer.
The product owner orders the product backlog and decides what gets built next. A scrum master coaches the team on the framework and clears blockers. Everyone else builds the increment as a developer, and the team stays cross-functional and self-managing.
Sprint planning opens each sprint and the daily scrum keeps it on track, while the sprint review and the sprint retrospective close it out. For a one-month sprint the guide caps planning at 8 hours and the retrospective at 3, with the review sitting at 4 hours.
The sprint review is where the feedback loop lives. The team shows the increment to stakeholders and reshapes the backlog, so customer input arrives once per sprint, which is slower than production telemetry in DevOps.
How DevOps connects development to release and operations
Under DevOps, development, testing, release and operations sit on one automated path from commit to production, and the people who build that path also keep the service running. It started as Agile applied to infrastructure. Over time it picked up engineering practices of its own and a culture of shared ownership.
Origin of the term
Flickr’s John Allspaw and Paul Hammond told the Velocity 2009 audience how the company ran more than ten deployments a day (IT Revolution). Patrick Debois, following from Belgium, organized a two-day conference in Ghent in late 2009 and called it DevOpsDays.
The roots go back further, to Agile 2008. Andrew Shafer proposed a session on agile infrastructure there, and Debois was the only person who showed up. The movement that followed is now called DevOps.
Pipeline stages
A DevOps pipeline moves every change through the same ordered stages. It begins with continuous integration, which merges each change into a shared branch and runs an automated build.
- Test automation runs unit and integration suites on every merge.
- With continuous delivery, every passing build stays releasable and a person approves the push to production.
- Continuous deployment drops that approval, so every passing build simply ships.
- Infrastructure as code defines servers and networks in versioned files.
- Monitoring sends production metrics and alerts back into the next change.
Continuous deployment sits on top of continuous delivery, so a team without reliable automated tests is not ready for it.
Ownership and roles
As a practice, DevOps means developers, operations and security share ownership of the pipeline and of what runs in production. As a role, it means a DevOps engineer who builds and maintains the pipeline and tooling for those teams, along with the infrastructure code.
The role helps until it turns into a gate. Matthew Skelton’s DevOps Topologies (2013) mapped how development and operations teams relate, and a standalone “DevOps team” parked between them recreates the handoff the practice exists to remove.
Feedback works differently here than in Agile. Production telemetry and deployment results, not a sprint review, tell the team what to change next.
Agile and DevOps tooling by job
Tools do not make a team Agile or DevOps. Each approach does lean on a recognizable stack, though, and the two stacks barely overlap.
- For planning and tracking, Jira holds the backlog and sprint board, and its velocity and burndown reports track completed and remaining work (Atlassian documentation).
- Jenkins, an open source automation server, and GitHub Actions run the build, test and deploy pipeline.
- Docker packages applications as containers, and Kubernetes orchestrates them.
- On the infrastructure side, Terraform defines everything in versioned files. Prometheus collects metrics and fires alerts.
Docker packs an application and its dependencies into a container image, so the build that passed testing is the build that runs in production. Kubernetes then schedules those containers across servers.
Terraform follows the infrastructure as code approach. Teams describe the desired end state in configuration files, and Terraform works out the changes needed. A state file records what exists, so infrastructure changes get reviewed in version control like application code (HashiCorp documentation).
Prometheus, a Cloud Native Computing Foundation project, pulls metrics from configured targets over HTTP, evaluates alert rules and triggers alerts when a condition is met, according to its documentation. Those alerts are the production feedback DevOps teams act on.
Order matters more than brand names. A team without a working continuous integration build gains nothing from Kubernetes, so the pipeline and tests come first and orchestration later.
One habit worth borrowing from both sides is linking each ticket to the pipeline run that deployed it. That’s where sprint planning meets delivery data.
Velocity vs DORA metrics and what each one measures
Velocity tells you how much planned work one team finished in a sprint. DORA’s delivery metrics are about something else, namely how fast and how safely changes get to production.
Jira’s velocity chart tracks work completed from sprint to sprint, and the burndown chart tracks work remaining against the sprint goal (Atlassian documentation). The burndown axis follows whatever estimation statistic the team configured, so velocity compares a team only with its own past.
DORA splits its five metrics into two groups. Throughput covers lead time for changes, deployment frequency and failed deployment recovery time. Instability covers change fail rate and deployment rework rate.
Deployment rework rate is the share of deployments that are unplanned fixes for production incidents.
Until 2024 the set had four metrics. The 2024 Accelerate State of DevOps Report added deployment rework rate and moved failed deployment recovery time, which the 2023 report had renamed from time to restore service, into the throughput group. With its September 2025 report, DORA renamed the study State of AI-assisted Software Development.
The same report replaced the low, medium, high and elite tiers with seven team archetypes. Plenty of guides still list four metrics and the old tiers.
DORA’s 2025 report ties AI adoption to higher delivery throughput and, in the same data, to higher instability. With 90% of respondents using AI at work (Google Cloud, 2025), a rising deployment frequency says little until change fail rate and rework rate sit beside it.
Digital.ai’s 18th State of Agile Report, released in October 2025, drew nearly 350 participants, mostly Agile coaches and consultants at enterprises with over 20,000 employees. DORA’s 2025 survey reached nearly 5,000 technology professionals across industries.
Those samples differ, so adoption and satisfaction figures from the two reports cannot be stacked into one comparison. The 95% Agile adoption figure and the 76% of respondents with a DevOps initiative underway or planned, both still quoted from the 14th State of Agile Report, are four editions old.
A few figures from the current DORA and Agile reports are worth keeping in view.
- DORA’s current software delivery set has 5 metrics, up from 4 since the 2024 report (DORA, 2024).
- Seven team archetypes replaced the four performance tiers (DORA, 2025).
- Nearly 5,000 technology professionals were surveyed for DORA’s 2025 report.
- Digital.ai’s 2025 State of Agile survey had nearly 350 participants.
Use velocity to plan the next sprint and DORA metrics to judge the delivery system. Mixing the two purposes turns both into targets.
Can Agile and DevOps run in the same team?
Yes. Agile supplies a steady flow of small, well-scoped changes, and DevOps supplies the path that carries them to production. Scaled Agile, the company behind SAFe, makes the same case from the pipeline side, arguing that DevOps without Agile leaves the pipeline underused.
The overlap is small batches. DORA’s capability catalog lists working in small batches as a way to shorten lead times and speed up feedback, and a backlog cut into small items produces exactly that.
Release timing is where the two bump into each other first. Teams that hold finished work for the sprint review stretch their software release cycle to the length of the sprint, although the 2020 Scrum Guide says an increment may reach stakeholders before the sprint ends and that the Sprint Review is not a gate to releasing value.
The meaning of done causes the other clash. The same guide counts work toward an increment only when it meets the team’s Definition of Done, so adding deployed to production with monitoring in place to that definition pulls the pipeline inside the sprint.
On the DevOps side of the combination, CALMS stands for culture, automation, lean, measurement and sharing, and teams use it to judge how ready an organization is for DevOps. SAFe has its own version, CALMR, added when Scaled Agile built DevOps into the framework in 2018. It treats sharing as part of culture and adds recovery instead.
Both put culture first. In practice that means collaboration between development and operations teams has to exist before any tool choice matters.
Credit for CALMS is contested. Many guides give it to Jez Humble alone, while the book SAFe for DevOps Practitioners traces the original CAMS to John Willis and Damon Edwards at the 2010 DevOpsDays, with Humble adding lean.
Some comparison guides also claim DevOps has no widely accepted framework. CALMS is the closest candidate, and TechTarget describes it as a way to measure maturity, not a replacement for other development methods.
Choosing between Agile and DevOps by team and product
Start by finding the stage where work waits longest. When it’s stuck on requirements and priorities, Agile practices come first. When finished code just sits there between commit and a running release, that’s a DevOps problem.
To find that stage, split lead time for changes into queue time before coding, review wait, build and test duration, approval wait and deployment.
Waiting on priorities or scope means refining the backlog and shortening the feedback loop with stakeholders. Waiting on builds, approvals or manual releases means automating the build, test and deploy path.
If it’s both, fix the release path first. Faster planning only piles more finished code behind a slow release.
Team size shifts the odds. In Digital.ai’s 17th State of Agile Report (January 2024), 52% of small organizations said Agile works very or somewhat well, against 43% at larger companies.
A single small team gets most of the benefit from Scrum or Kanban plus a basic pipeline. Many teams sharing environments need dedicated pipeline ownership before more ceremonies help.
The reason a team ships rarely is what decides it. Manual, risky releases point to DevOps. Fixed external release windows point to Agile planning, and deployment frequency can be left alone.
Cost differs too. Agile mostly costs process time. DevOps costs tooling budget and pipeline upkeep, and it adds on-call load.
| Option | Pros | Cons |
|---|---|---|
| Agile alone | Clear priorities, fast feedback on what to build | No release path, so shipping stays manual and slow |
| DevOps alone | Fast, repeatable releases and production feedback | Nothing decides what to build or in what order |
| Both together | Small changes flow from backlog to production | Process, tooling and on-call overhead |
The obvious move for a struggling team is another Agile framework. If releases are manual and take days, though, continuous integration and automated deployment pay back sooner. DORA’s capability catalog lists both, together with test automation, among the capabilities that drive delivery performance.
Adding DevOps practices to an existing Agile team step by step
Add DevOps practices in the order a change travels, starting with a measured baseline and ending with monitoring that feeds the backlog.
- Map the path from merged code to production and record a baseline for lead time for changes, deployment frequency and change fail rate.
- Put application code, pipeline definitions and environment configuration under version control.
- Add continuous integration so every merge triggers a build and automated tests, and keep branches short-lived (trunk-based development).
- Automate deployment to staging, then to production, using the same script for both.
- Define environments as code so a new one can be rebuilt from files.
- Add production monitoring and route alerts into the team’s backlog.
- Re-measure after each change and compare the result with the baseline.
Step 2 goes wrong when pipeline changes slip through unreviewed. Pipeline files and infrastructure definitions change production behavior, so they need the same pull request review as application code. Editing settings in a web console loses the history that version control exists to keep.
Flaky tests are the usual trouble at step 3. Google’s testing team reported in 2016 that about 1.5% of all test runs came back flaky, and a 2017 breakdown found 14% of large tests flaky against 0.5% of small ones. A suite built mostly from large end-to-end tests fails at random and eats investigation time, so keep the bulk of it in fast unit tests.
Alert overload is what sinks step 6. Page a person only for conditions that need a human, and send everything else to a dashboard. Alerts nobody acts on get muted, and once an alert is muted the feedback loop has a gap in it.
When Agile and DevOps break down
Sprints with no path to production are where Agile falls apart. DevOps hits its limit where an approval or certification step caps how often a change can ship. Neither is really a flaw in the approach. It’s a mismatch with the constraint.
Scaling is where Agile gets bumpy. Digital.ai’s 17th State of Agile Report (January 2024) found only 11% of respondents using Agile very satisfied and 33% somewhat satisfied, with medium and larger companies reporting the most trouble scaling. A team can hold every ceremony on schedule and still release once a quarter, which is how velocity ends up measuring activity instead of delivery.
Regulated environments add their own wrinkle. Formal change management often routes every release through an external approval board. DORA found no evidence that such review lowers change fail rates, and its guidance favors peer review at check-in supported by automated tests (2019 State of DevOps Report).
The board often exists to satisfy a regulator, so any replacement has to leave the same audit trail. Capital One automated its change control and moved to trunk-based development with DORA’s help, and DORA’s 2017 case study reports releases up 20x with no increase in incidents.
Medical devices and certified software sit under heavier rules. AAMI TIR45, first published in 2012 and updated in 2023, guides manufacturers who use Agile practices while following IEC 62304 and FDA expectations for device software (AAMI; Johner Institute). The documentation, traceability and other software compliance duties stay in place, so continuous deployment fits poorly, while continuous integration and test automation still apply.
Embedded and hardware-bound releases are a different case again. Firmware flashed onto physical units, or software tied to a certification cycle, ships in fixed windows. Deployment frequency stops being a goal there, and change fail rate becomes the number to watch.
A team has probably built more process than it needs when pipeline upkeep takes more time than feature work, or when retrospectives keep repeating the same action items. Alerts outnumbering the people who can act on them is another sign.
Agile vs DevOps FAQ
Is DevOps a methodology or a culture?
Both. DevOps pairs technical practices such as continuous integration and infrastructure as code with a culture of shared ownership.
DORA’s capability catalog covers the same range, from technical capabilities such as continuous integration and deployment automation to cultural ones such as a generative organizational culture.
Does DevSecOps replace DevOps?
No. It’s DevOps with security checks built into the pipeline instead of added at release.
DORA’s capability catalog includes pervasive security, which builds security into the software development lifecycle, so it extends DevOps rather than replacing it.
How does site reliability engineering relate to DevOps?
Benjamin Treynor Sloss, Google’s SRE founder, calls it a specific implementation of DevOps with idiosyncratic extensions. In other words, SRE is a prescriptive way to run DevOps.
The best known extension is the error budget, which pauses releases once a reliability target is missed.
Why does Agile still matter with AI-assisted development?
AI speeds up writing code, but deciding what to build and adapting when requirements change stays with the team, and that is the work Agile organizes.
Digital.ai’s 18th State of Agile Report (2025) says AI is refocusing organizations on Agile’s original intent, which is rapid adaptation to change.
The ongoing cost of running Agile and DevOps together
Most of the recurring cost of running both lands after launch, in pipeline upkeep and on-call duty, plus incident work. Google’s SRE book (2016) cites estimates that 40 to 90% of a system’s total cost accrues after launch.
Google caps operational work at a 50% share of SRE time and hands the excess to product developers. The SRE Workbook adds that the figure will not fit every organization, yet any upper bound makes toil, the repetitive manual operational work, measurable.
The sequence follows from the cap, which needs a measured baseline. Measure toil and rework first. Then cap operational work and route the overflow to the product team, and after that automate the largest repeating task.
The trade-off is that overflow lands on the product team’s backlog and slows planned delivery. Budget for post-deployment maintenance as a standing line item, not a one-off project.
- VS Code Extensions That Are Actually Worth Installing - October 13, 2026
- Google Play App Signing Explained - October 11, 2026
- 5 Best NinjaOne Alternatives for Focused Endpoint Management - October 10, 2026
