Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock () or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

We’re working on a new version of

We’re adding tools to help GSA deliver a digital-first public experience. You can track our progress in our open-source repository.

Agile vs. Waterfall- Scope, Schedule and Cost

Understanding the Differences

Agile is a value-based, iterative approach under which business needs and solutions evolve through the collaborative effort of self-organizing cross-functional teams. Agile advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. The traditional Waterfall approach is a sequential process of a series of activities or phases that need to be complete before moving forward to start a new phase. The requirements are identified upfront and the customer does not have the opportunity to interact with the product and provide feedback until the final product is delivered. If there is a change to be made after the final product has been delivered, there will be a high-cost associated with it since there was no prior opportunity to course-correct and the changes have to go through the full process again.

Traditional Waterfall Approach Agile Approach
Sequential product development/delivery process where each phase needs to be complete in order Time boxed and iterative/incremental product development/delivery
Requirements and design decisions are made upfront Product Owners and Development Team have the opportunity to negotiate and re-prioritize requirements throughout the development process
Months of planning before development begins Intermediate milestones: deliver in deployable increments with useful features, it may have minimum viable product functionality
Broken into stages that need to be completed before you can go to the next Complete transparency in development process, each iteration/sprint delivery is done when it is programmed, tested, and so on
The customer sees the product for the first time when final product is delivered Customer is constantly interacting with product and providing feedback
Making changes so late in the process can be expensive and time-consuming Changes are embraced in the iterative process through constant communication and prioritization
Only one initial investment to be spread out over the project timeline Incremental investment process where money is released with phases

Agile Investment Approach

What is the Agile Investment Approach?

All pilots begin with an approved Business concept. Once the Product Owner and Scrum Team members are identified, the CTO Office then engages the right resources for Discovery that will lead into the Proof of Concept (PoC) phase and beyond.

Agile Investment process

Why use an Agile Investment Approach?

During the Discovery Phase, a goal is set and the team will identify 1-2 high-value use cases that will quickly acknowledge whether the solution chosen is the right one to meet business needs. Right away, every sprint (typically 2-3 weeks) allows stakeholders to see and track progress.

Measuring Success

While a traditional waterfall approach can work well for projects with routine and predictable requirements, an agile approach is a better fit for large cross-functional, complex products because it allows you the flexibility to make changes to requirements as they become available.

Agile vs Waterfall graph

In the phased investment approach, an agile team learns early what works and what does not, which gives them more knowledge on the product and alternatives. Releasing the funds in increments allows an agile team to better inform investment decision-making and potentially reduce their overall spending. The advantage of the incremental approach is that the team learns early, fails early, and can course-correct while the budget is still intact.

Often times, in a Waterfall approach, defects are not discovered until the end of the process when testing takes place. Once the errors are exposed, the team has to retrace steps back to the beginning, while the project budget and schedule are both at risk.

In order to measure success, a product must meet the success criteria determined at the beginning of the project. Typically, the criteria will include meeting all customer requirements and business lines getting to see the product early and making decisions. These decisions are an important part of determining success as they range from the ability to learn early and stop before spending all funds, to if the product plan proves not feasible during the discovery or proof of concept phases. / Office of the CTO

An official website of the U.S. General Services Administration

Looking for U.S. government information and services?