Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Agile vs. Waterfall: When is each approach to software requirements best?

When it comes to choosing between Agile or Waterfall projects, Agile proves more valuable for helping development teams and stakeholders retain focus on the right software requirements.

Establishing software requirements can be challenging. It is not easy to gain a good understanding of customer...

requirements, let alone document and maintain those requirements when they change over time.

Agile vs. Waterfall: Projects and software requirements

When you compare Waterfall and Agile projects, you'll see they have different approaches to managing software requirements.

Agile has proved to be valuable because it helps development teams and stakeholders stay focused on delivering software that satisfies customers' most important requirements as quickly as possible. With Agile and its frequent feedback cycles, development teams and stakeholders can stay focused on the right requirements.

Breaking down Waterfall projects

In contrast, Waterfall projects aim to define all software requirements upfront and document them with such detail that project teams can develop satisfactory software products without change. This approach puts pressure on customers to come up with every requirement they might need before a prototype has been delivered. When software requirements do change, Waterfall projects use change management to adjust the requirements -- often a time-consuming and costly process.

I've seen Waterfall projects that started with a long list of software requirements, but in the end many features were never used. Even worse is when needed functionality is overlooked at the start of the project, and hence isn't in the requirements. Getting the requirements right, and keeping them right during a project, is close to impossible with a Waterfall project.

Zeroing in on the Agile approach

Now let's explore how Agile addresses software requirements differently, and how the Agile techniques help development teams focus on satisfying the right requirements. The Manifesto for Agile Software Development puts working software above comprehensive documentation. Agile frameworks like scrum or XP suggest development teams should deliver software in iterations. Backlogs with user stories are used to manage requirements. At the start of the iteration the team and stakeholders agree upon which requirements will be satisfied with the next delivery. By collaborating in this way, everybody is focused on delivering the most important features.

Agile projects begin with the assumption that you can't get all the requirements right at the start. Continuous improvement is built into Agile projects, both from a product and process perspective. To improve software project requirements, Agile frameworks provide practices such as planning games, backlog grooming sessions and software demos. When Agile is used, requirements are updated continuously as new information and insights become available.

Success factors for focusing on the right software requirements with Agile projects are:

  • Frequent interaction between the stakeholders and development teams
  • Focusing on the value that a requirement can deliver to customers
  • Deploying Agile requirement practices effectively

Agile vs. Waterfall: Both call for frequent, detailed interaction

There has to be frequent and detailed interaction between the team and the stakeholders. It's important to establish trust and build a relationship were people can be open and honest. This eases communication and supports building a common understanding of the right requirements.

For me, value matters more than costs. If you know which requirements will be most valuable, then the costs for developing them often become less of an issue. Understanding the value also motivates people, and helps them focus on continuously selecting and developing the right requirements.

Using an Agile project framework like scrum, XP, SAFe or LeSS doesn't automatically guarantee success. You have to deploy the framework in a way that suits your needs. Pick suitable practices and agree upon your way of working. Don't worry about not having a perfect process at the start; practices such as retrospectives will help you to learn and fine tune things along the way.

Agile vs. Waterfall

For more about the Agile Manifesto check out Jenn Lent's columns on whether the Agile Manifesto is 'anti-planning' and whether or not the Agile Manifesto is still relevant. Another good resource is this excerpt from Agile Foundations by Peter Measey and Radtac.

To learn more about Waterfall:

Next Steps

Agile development myths

Agile best practices

Combining Agile and Waterfall

I want to break up with Waterfall; my company doesn't

This was last published in June 2015

Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

19 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Agile vs. Waterfall: Which software development model has been more valuable for you?
Cancel
Agile hands down.  Producing products parts early, pivoting and changing when needed seems so much better than the old formalized waterfall model.
Cancel
Thanks Timothy for your vote and for explaining why you favor agile.
Cancel
Agile is great for risky work that you are committed to getting done as quickly & effectively as possible, so you want to expose problems early to learn and validate your approach as you go. You might fail, but you'll fail quickly, at minimal expense. Nothing beats Waterfall for risky work that you are committed to milking for as long as possible, so you want to defer exposing problems that might invalidate your approach. You'll probably fail, but it won't be apparent for months/years, giving you plenty of time to find scapegoats, and/or move on to your next big WaterFail project.
Cancel
That doesn't sound like a good recommendation for waterfall when looking at requirements. When things start changing, as often happens, project will go on forever.
Cancel
I think it is going to be dependent on the size and clarity of the initial requirements. If the product being deployed is a straight forward and that doesn't allow too much of customization then Agile would work perfectly. But if it is something like a complex SAP ERP installation I would recommend Waterfall method to make sure nothing is missed in the requirement gathering phase as the modules are so integrated and translating requirements at a later stage may be an expensive affair. Both methods have their own merits and demerits so use them wisely.
Cancel
Thanks for your reaction Vasu.

I have a question. For years organizations have struggled with delivering large complex systems. Many projects that usef waterfall failed in getting requirements complete and  correct. Agile came as a reaction to this, by working intensively together with customers using iterations and frequent feedback to deliver what was really needed. 

What's your view on this? 
Cancel
I think the important selection criteria has more to do with repeatability and with the type of project. Agile works well with software development projects where you can create a distinct list of features that you want, then start developing them one at a time.  A good example would be the development of a new website where you can concentrate on getting one page up and running before you work on the next one.

Waterfall can be very effective if you have a repeatable project.  For example, if you are standing up a new server (or a clone of an existing website), defining all of the steps up front and managing to that plan works much better than trying to determine what "the next most valuable feature" is.

Off-the-shelf software is a special case where you need a mixture of both techniques.  For example, with an ERP system, you really need to get your Chart of Accounts operational before you set up Accounts Payable or Inventory.  However, Agile techniques can be applied quite effectively to determining how to address the financial reporting needs of the organization.

IMHO Agile vs. Waterfall has become a classic "Mac vs. PC" fight with avid evangelists on both sides.  What often gets lost in the debate is the true benefits that each method can bring to the conversation.  The key question is not "Which method is better?" The key question is: "Which method is better for the task at hand?"
Cancel
Hi Ben,
Agile may work is some of the situations if the time is very flexible. In a complex ERP project there are some much of dependencies, waiting for one requirement to completed on multiple iterations could mean delayed deliverable and project
Cancel
There are strengths in both waterfall and agile, I like your though on which method better suits the task at hand sharper101. At the same time I see that organizations often have difficulties combining practices from different methods. But that's another story to explore I guess.

My experience is that agile can actually help you to come to a list of prioritized features. There are many agile practices that can help you with this. But you need to invest time, and teams need to work intensively with their customers to get there.
Cancel
Thanks Vasu for your clarification.

Do you have some examples of how waterfall deals with complexity and dependencies. I'm interested in the practices that are used, as they might also be suitable in agile projects?
Cancel
I feel Agile is the way to go. And even before we embrace the agile process, we must understand the agile thought. That helps us really understand how to leverage agile in our projects. As Picasso said

Learn the rules like a pro, so you can break them like an artist.

For enterprises as well as non-enterprises, one thing that doesn't change is the need to be in sync with the market and its direction. So even for complex projects like implementing an ERP or a CRM solution, the method to building/implementing it can be agile wherein you ensure that at the end of every sprint you have a product that works and is usable. Not only is it less risky, it takes us away from the older model of big bang projects. It enables orgs to build based on needs rather than what IT wants to build.

So I think waterfall model esp in its original form is not really a healthy way to go forward.


Cancel
Thanks aishwaryam for sharing your opinion. 

To get real value from agile it helps a lot if you have an agile mindset. Believe in the agile principles and a understand the agile practices, so that you can adapt your processes to suit you best.

Reading your reaction, do you agree that agile can bridge gap between IT and business? Do you have examples from your own experience?
Cancel
My current example is the product that I am currently building RobusTest.com

I agree, that in this example the business itself is that of IT. That should not really make a difference.

In our case, market requirements change almost every week because the mobile devices and apps are constantly updated with new features. It is not possible for us to start even a one month "project". As and when we come across features that need to be built, we add them to our feature backlog and from there they get scheduled for a sprint. Following an agile methodology allows us to respond to market conditions which, in a way, is our raison d'etre.
Cancel
Great example aishwaryam, thanks for sharing this!
Cancel
The real challenge with Agile is the cultural changes required to make it successful.  If senior management is not actively onboard, the most well-intentioned Agile initiatives will fail.

Some of the key cultural challenges include: 

Management is often used to pulling their favorite developer to work on their favorite project.  Agile requires that they not do that and that can be a tough lesson for them to learn.

Developers need to learn new skills and attitudes.  Many developers like to work as "lone wolves" and resent the type of transparency and accountability Agile methods bring to the table.  It is much more comfortable for a developer to say "I will give this to you in three weeks" than to say "This is what I completed yesterday and this is what I will complete today."

Developers and QA's need to agree on the definition of "Done".  Often the traditional definition has been when the software is coded and does not include the time and effort it takes to really do good testing (unit, QA, UAT, performance, integration, etc.).

Finally, the business people need to embrace the idea that they need to be actively involved in the project on a DAILY basis. Without that involvement, they often have the attitude that software projects should be like shrink-wrapped products -- I'll tell you what I need and you just need to pull the shrink-wrap off it and deliver it right now.

All of that being said, I have seen Agile methods deliver higher quality software with fewer defects, less "gold-plating", and greater customer satisfaction than any waterfall project I have worked on.  (I have been a project manager for over 15 years with the past 5 years doing Agile so have seen a few projects in my time.)

Still, we need to be careful to not assume that Agile is the "silver bullet" solution for all projects.  A careful up-front analysis of the pros and cons of Agile and waterfall will lead to the best method being chosen to address the particular needs of the project at hand.
Cancel
Thanks sharper101, great summary of what can make Agile successful. In the end it's not the method, but it's how people use it to do great things together. Collaboration is key to make Agile work!
Cancel
There are several indisputable truths working against Waterfall:
1. It's impossible to objectively know reality fully at any given moment in time.
2. Even if you could achieve 1, you would have to repeat it for the next moment and so on.

By its definition, Waterfall doesn't cope well with this right from the start. Having a "requirements gathering" phase upfront, with no other work until that's "done" is a no-starter because of the reasons above. Additionally, regardless of methodology, requirements "gathering" or "elicitation" is a fallacy anyway, it's not like the requirements are just sitting there in the users' heads, waiting to be "gathered". They might have some rough ideas, but from that to working software there's a long and bumpy road, with many changes as the needs and wants become clearer and probably better alternatives than initially envisioned present themselves. So, in the face of reality, Waterfall is dead on arrival.

One thing to note though is that the same problem exists with Agile methods, but sometimes it's exacerbated even more by the misunderstanding that in Agile "we don't need no requirements". The Agile manifesto is a good counterexample to this thinking, as it doesn't really take a "don't do this, do that" approach, it rather says it values more an Agile approach over the traditional one, though that still might have value (e.g. Communication and People are at the heart of Agile, rather than excessive formalization through process and tools).

In the end, it's a balancing act. For me personally what's important is to have an Agile mindset, rather than the particular implementation you use. It's important to recognize that people will make or break a project, not the tools they use. From there it's a matter of carefully balancing doing the work that will yield that greatest return now vs setting up for the greatest return in the next cycle. 

p.s.: regarding the degree of formalism recommended on a project, based on team-size and criticality, the Cockburn Scale might help https://en.wikipedia.org/wiki/Cockburn_Scale

Cancel
Thanks Adrian for your extensive reply!

I have also see waterfall project that failed to capture the requirements initially, where the requirements phase dragged on until the very end of the project or where team where overwhelmed with change requests during the project.

Also have seen agile teams who developed features without a good understanding of what their customers need, being stuck because the product owner wasn't available or having endless debates about their user stories.

In the end, my believe is that's it's not the method but the people that matter. Their skills, experience, qualities will make the difference.

Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close