From Waterfall to Agile and DevOps: Why the Feedback Loop Shrank from Months to Hours

Version note: This post is based on the history page of the Agile Manifesto (February 2001) and on the five-metric model of DORA (DevOps Research and Assessment) as published in November 2026.

Guess First

Think of Bookstore as it was in 2015: the team releases once every three months. In the first week of January a developer adds a change to the shipping fee calculation, and the change contains a rounding bug. When does this bug show up in production, and when it does, how much does the developer remember about what they were thinking while writing that code?

Now think of the same team as it is today, deploying several times a day. How many hours until the same bug shows up, and among how many commits is it found? The difference between the two answers is a summary of the fifty years this post is about.

A Short History: From 1970 to Today

In the earlier posts of the SDLC (Software Development Life Cycle) series we saw Royce's 1970 paper, the sequential model institutionalized through contracts, the V-Model and Spiral. In the 1990s a group of "lightweight" methods appeared as a reaction to these heavy processes: DSDM (Dynamic Systems Development Method) in 1994 through a consortium, Scrum in 1995 with Ken Schwaber and Jeff Sutherland's presentation at the OOPSLA (Object-Oriented Programming, Systems, Languages and Applications) conference, XP (Extreme Programming) from the project Kent Beck started in 1996 and his 1999 book, FDD (Feature-Driven Development) in 1997 from Jeff De Luca's bank project, and the Crystal family of methods from Alistair Cockburn's work.

In February 2001, 17 people representing these methods met at Snowbird in Utah and wrote the Agile Manifesto. The Manifesto's values and principles are the subject of a separate series, Agile Mindset; Agile's evolution after 2001 is in the last post of that series. The line that matters here is this: Agile shortened the feedback loop from months to weeks, but the last link of the loop, getting to production, was still slow in many teams.

The movement that shortened that link got the name DevOps in 2009. In June of that year John Allspaw and Paul Hammond explained at the Velocity conference how development and operations teams at Flickr worked together to deploy more than ten times a day. In October Patrick Debois organized the first DevOpsDays event in Ghent, Belgium. In 2010 Jez Humble and David Farley's book "Continuous Delivery" systematized the idea that every commit passes through an automated deployment pipeline and becomes releasable.

The Real Variable: Deployment Cost and Batch Size

It's easy to read this history through method names, but the underlying variable is economic. Getting a change to production has a fixed cost: build, test, approval, deployment, a rollback plan. While this cost is high, it seems sensible to accumulate changes and ship them in big packages. In 1970 a release was sent to the customer on magnetic tape, in the 1990s it was distributed on compact discs; the fixed cost of a release was weeks of work.

Accumulating also has a cost, and that cost is invisible. As Don Reinertsen explains in "The Principles of Product Development Flow" (2009), as the batch grows, the cost of waiting work, the risk and the feedback delay grow too. If 140 commits go out together in Bookstore's three-month release and something breaks in production, the question becomes "which commit?" and the answer can take days. In a daily release the same question is answered among three commits, within an hour. And the developer who wrote the bug still remembers the code.

As deployment automation, cloud infrastructure, containers and automated tests lowered the fixed cost, the optimal batch got smaller. In that sense Agile and DevOps are as much a shift of a cost curve as a change of philosophy. The bottom band in the figure shows this: the release interval dropped from years to hours because the cost of a release dropped.

The Loop Shrinking at Bookstore

Let's follow Bookstore's transition in three periods. In the first period a release happens every three months, together with a two-week "stabilization" period; the test team tries all the changes together during that time. The time it takes a developer to get feedback from production on a change is close to six weeks on average.

In the second period the team moves to Scrum and runs two-week sprints. But the release process doesn't change: the output of the sprints accumulates on a release branch and still goes out every three months. The team says "we're Agile"; the loop the customer sees is the same. We'll come back to the name of this situation in the pitfalls section.

In the third period the team moves to trunk-based development, an automated deployment pipeline built on CI (Continuous Integration) and CD (Continuous Delivery) principles and feature flags. Every merge goes to staging if it passes the tests, and to production after approval; unfinished features sit switched off behind a flag. The shipping fee bug now shows up as an alert an hour after deployment, and rolling back means reverting a single commit. Branching strategies are in the Git & GitHub series post "Teamwork with Git: Branching Strategies, Rulesets and Conventional Commits", and setting up the pipeline is in the ASP.NET Core Web API (Application Programming Interface) series post "Containerizing an ASP.NET Core Web API with Docker and Setting Up CI/CD with GitHub Actions".

Measuring the SDLC: DORA's Five Metrics

You know whether the loop has really shrunk by measuring it, not by guessing. The DORA research program at Google has been measuring software delivery performance for more than a decade. The model, which started with four metrics in 2014, now consists of five; the fifth was added in the 2024 report. The metrics fall into two groups:

One of DORA's most important findings is that speed and stability are not opposites: top-performing teams deploy more often and also have fewer failures. The reason is again batch size; small change, small risk. The metric names have also changed over time; for example the old MTTR (Mean Time to Restore) became failed deployment recovery time in 2023, limited to failures caused by deployments. How these metrics are calculated from pipeline data is covered in the CI/CD Fundamentals series post "Measuring and Speeding Up a Pipeline: DORA Metrics, Caching and Parallelism".

Secure SDLC and Shift-Left

As the loop shortened, security had to move inside the loop too. Adding a security test at the end of a release every three months was possible; in a team deploying ten times a day, security checks have to be a step of the pipeline. Shift-left means pulling checks to the left in the life cycle, into the requirements, design and coding phases: threat modeling in design, static analysis and dependency scanning while coding, secret scanning in the pipeline. The vulnerabilities themselves are in the Web Security (OWASP Top 10) series; how to add these checks to the pipeline is the subject of the upcoming DevSecOps series.

Production Notes

Measure today's loop first. Writing the commit time and the production time of the last ten changes side by side is a good enough start for change lead time. When most teams do this for the first time, they see that most of the time is spent not writing code but waiting for review, approval or a release window.

The most effective tool for shrinking the batch is separating deployment from release. With feature flags, code can go to production every day, while enabling it for users becomes a separate decision. This separation removes the "we can't deploy until this feature is ready" blocker.

Don't force speed without test automation. In a system tested by hand, increasing deployment frequency does nothing but increase the change fail rate. The order matters: first a reliable pipeline, then frequent deployments.

Common Pitfalls

Saying "we moved to Agile" while still releasing once a quarter is the most common pitfall. The term water-scrum-fall, popularized by Forrester analyst Dave West's 2011 report, describes exactly this: a Waterfall-like planning and budgeting process up front, Scrum sprints in the middle, and again a big Waterfall-like release at the end. The team's inner loop has shrunk, but the loop the customer sees hasn't changed.

The second is thinking DevOps is a team name or a tool. A new team set up under the name "DevOps team", to which developers hand over the deployment work, doesn't remove the wall between development and operations; it just moves the wall.

The third is turning DORA metrics into targets. If deployment frequency becomes a performance target, teams split changes into meaningless pieces; the metric improves, the loop doesn't. The metrics exist for a team to see its own improvement, not to compare teams with each other.

A Small Experiment

★☆☆ Calculate the change lead time for your team's last ten production deployments: what is the median difference between commit time and deployment time? In which stage does the time wait the longest?

★★☆ Take three bugs that appeared in production last quarter. For each, how many other changes went out together with the change that contained the bug, and how long did it take to find the source of the bug?

★★★ Does your team's current process look like water-scrum-fall? Write the length of the feedback loop for each of the planning, development and release stages, and propose one concrete change to shorten the longest one.

The line of fifty years is clear: the loop got shorter. But that doesn't mean every project should use the same model. In the last post of the series we discuss how to choose the right SDLC model for a project by looking at factors such as requirements uncertainty, regulation, contract type and deployment cost.