Agile vs. waterfall
"Waterfall is the past. Agile is the future." This may sound like an oversimplification, but it is how many developers think. It is easy to dismiss waterfall as an antiquated way of building products. And if you are a proud agile practitioner (or you simply aspire to join an agile development team), the temptation to reject waterfall can be even greater. Because you are aware of the benefits that often come with a flexible and incremental approach to delivering software — greater efficiency, improved collaboration, and a stronger understanding of what customers want.
But it is a mistake to overlook waterfall entirely. The best developers know that being agile is not the only way to deliver value to customers. After all, different elements of agile and waterfall can be useful depending on what you are building, the type of organization (and team) you belong to, and which stage of the product development process you are in. Being a knowledgeable and well-rounded programmer means that you can adapt and tailor your workflows — you can apply the most relevant aspects of each methodology to your development work.
This is why it is helpful to have a deep understanding of both agile and waterfall. Let's start with a brief history of each and then explore the benefits and drawbacks of these different frameworks for developing products.
History of waterfall and agile
The origin of the waterfall approach is typically attributed to two academic papers published in the 1970s — "Managing the development of large software systems" by Dr. Winston W. Royce and “Software requirements: Are they really a problem?” by Thomas E. Bell and T. A. Thayer. While Royce's paper explained how teams can follow a series of steps to deliver on time and on budget, Bell and Thayer's work focused on the importance of beginning projects with a clearly-defined set of project requirements.
Over the next two decades, waterfall became the prevailing development methodology as companies across industries adopted a sequential model to delivering products. But many engineering teams eventually grew frustrated with waterfall's rigid approach — they struggled to deliver working products efficiently amidst bureaucratic bloat and micromanagement. This over-reliance on process over productivity led many software practitioners to search for a better way of working. At the same time, major technological advancements led many companies to prioritize a faster time-to-market. In order to build successful software-based products and services, organizations needed a way to speed up the product development process and gather customer feedback about new functionality.
In 2001, 17 software practitioners met in Utah to formalize a new way of working — agile. They incorporated a variety of ideas from existing methodologies including iterative and incremental development (IID), evolutionary delivery (EVO) and rapid application development (RAD). The goal was to help organizations achieve a competitive advantage by bringing new products and functionality to market faster and delighting customers. The group captured four key values and 12 agile principles in a document that became known as the Agile Manifesto. Since the early 2000s, organizations of all kinds have adopted agile methodologies and undergone agile transformations to work faster and achieve their business goals.
Now that you have some context for the evolution from waterfall to agile, let's take a closer look at the advantages and disadvantages of each methodology.
What is agile?
Agile is a flexible approach to software development. It prioritizes adaptive planning, short feedback loops, and frequent delivery of value. Agile teams collaborate closely and move quickly to bring new products and functionality to customers. Frequently gathering and incorporating user feedback is an important part of delivering offerings that align with exactly what customers want.
Here are some of the main benefits of taking an agile approach:
Greater speed and efficiency
Ability to pivot and make changes throughout the product development lifecycle
Increased customer collaboration and input can lead to greater customer delight
Improved planning as you develop an understanding of the team's velocity
But agile is certainly not perfect. Some agile teams (or teams that aspire to be more agile) struggle with a variety of challenges, from a lack of overall strategy to developer burnout.
Here are some common pitfalls of being agile:
Pivoting too quickly without considering the broader company and team goals (the reason behind the work)
Inserting too many rules and prescriptions into workflows
Gaining necessary buy-in from the organization
Failing to take the time to address technical debt along the way
What is waterfall?
Waterfall describes a sequential model for planning, building, and delivering new products. Requirements are defined upfront and each project typically moves through six distinct phases: requirements analysis, design, implementation, testing, deployment, and maintenance. In each phase there are specific activities that the waterfall team must document and complete. Before proceeding to the next phase, some organizations choose to conduct a stage gate review — an assessment of status, risks, cost, and schedule. This gives the team a chance to make sure the project is ready to move to the next phase.
These are some of the key benefits of taking a waterfall approach:
Planning and design stages can be more straightforward since you agree upfront on project requirements, scope, and deliverables
Structured processes can make it easier to meet compliance requirements
A more holistic approach to planning can make it simpler to determine the cost of projects upfront
But for many development teams, the problems with waterfall outweigh the benefits. This is especially true at software companies and organizations with products that rely on frequent customer input.
Here are some common problems that you might encounter with a waterfall approach:
Requirements can be poorly defined which leads to the wrong thing being built
More rigid workflows mean that there is no way to adapt as you go
Strict timelines can cause developers to feel overwhelmed as they struggle to complete everything that was defined upfront
Minimal customer involvement during the product development process can lead to customers who are unhappy with the final product
High opportunity cost since projects often take so long to finish that the original project requirements may have changed (or a competitor may have built a similar product first)
Minimal collaboration between teammates leads to less collective accountability for the quality of the work (ex: a developer hands off their portion of the project off to QA and the two functions do not communicate further about the work)
What are the differences between agile and waterfall?
Now that we have looked at agile and waterfall on their own, let's examine the differences between these two methodologies. Remember: most teams are not entirely agile or entirely waterfall. Instead, they adopt a hybrid approach (sometimes called wagile) that fits their particular needs. For example, some development teams adhere to the more rigid deadlines required for waterfall planning but eschew extensive documentation so they can make decisions faster.
Here is a closer look at the main areas where agile and waterfall diverge:
Agile | Waterfall | |
Goals | Continuously deliver value to customers and adapt plans based on changing business, market, and customer needs. Success is measured by progress towards strategic goals and customer-centric goals such as user happiness and growth. | Deliver the initial scope on time and within budget. Success is measured by project delivery. |
Approach | Incremental, iterative, and flexible. Agile teams usually work in cycles of two to four weeks called sprints. They constantly gather customer feedback to iterate on plans, refine requirements, and discover new solutions to add to their agile roadmap. Features are prioritized based on the needs of the business and customers. | Linear, sequential, and structured. Waterfall teams move more slowly — they gather requirements up front and prioritize features in a product requirements document. Each project moves linearly through six phases: requirements analysis, design, implementation, testing, deployment, and maintenance. |
Testing | Testing occurs at the same time as development. | Testing occurs after the implementation phase. |
Release cadence | Deliver new products and functionality regularly and frequently. | Deliver new products and functionality more infrequently on a fixed schedule, usually at the end of a project. |
Variables (time, cost, and scope) | Cost and time are stable, but the scope — or the product you will build and deliver — varies. Agile teams can reduce scope by shipping whatever working software is completed by the release date. | Scope and project requirements are set up front, but cost and time can vary. Many development teams using the waterfall model find that cost and time increase since projects are rarely delivered on time. |
Roles | Agile teams that follow scrum include the following roles: scrum master, product owner, and development team. | Teams include the following roles: Project manager, business analyst, stakeholders, QA, and development team. |
Collaboration | High level of coordination between members of self-organized teams. Daily meetings, weekly check-ins, and regular retrospectives give teammates frequent opportunities to discuss their progress and raise concerns. | Team members work together to complete activities during each phase, but are typically more siloed with limited collaboration between different functions. |
Metrics | Agile metrics or KPIs help teams track progress, productivity, and performance — highlighting areas for improvement. They are also useful for setting goals and motivation. Some of the most common agile metrics are burndown, velocity, cycle time, cumulative flow, and team happiness. | Waterfall metrics or KPIs help teams monitor project delivery and determine if progress is on schedule and on budget. Some of the most common waterfall metrics are cost variance, schedule variance, work delivered vs. work planned, and customer satisfaction. |
Adjusting your methodology to your needs
The methodology you use will depend on your particular industry, company, product, and team. The waterfall model, for instance, can be useful if you are working on projects with a fixed scope, strict budget, unchanging requirements, or highly complex dependencies. This is why industries that produce and deliver physical products — such as manufacturing and construction — still often use waterfall. The same is true for companies that sell hybrid products (with both hardware and software components).
The majority of SaaS organizations, on the other hand, greatly prefer agile frameworks such as scrum, kanban, and the Scaled Agile Framework® (SAFe®). Teams use agile so they can move quickly and pivot in response to new customer feedback. The overarching goal is to make customers happy by continuously delivering valuable software.
When you appreciate the unique benefits of each framework for delivering new products, you can make more informed decisions about which methodology (or which elements of each methodology) to use. You can focus less on labels and more on the practices and workflows that make sense given the specifics of your team and use case. And ultimately you can improve your offering and deliver greater value to users.
Aha! Develop is a fully extendable agile development tool. Sign up for a free 30-day trial to learn how you can customize the way you work and deliver more happiness to customers faster.
