Agile vs Waterfall-Success-Failure Rates

Waterfall vs. Agile

Last updated: January 27, 2020

What is the Difference Between Waterfall vs. Agile?

According to the 2011 CHAOS Manifesto from the Standish Group, Agile projects are three times more successful than Waterfall projects.

The graph below shows the specific results reported from a study conducted based on projects executed from 2002 to 2012. They define a successful project as “on time, on budget, and with all planned features.“

Agile-Waterfall-Success-Failure-Rates

While the use of Agile methodologies in organizations is increasing, many are still unclear on what differentiates Agile and Waterfall, and how to effectively utilize both processes.

This slideshow on the two methodologies starts off with the following thought-evoking quote: “Agile leaders lead teams, non-Agile ones manage tasks.” As this mindset continues to grow – particularly in the product development and IT sectors – Waterfall is gaining a reputation as the “old-fashioned” way of thinking and working.

The difference between Waterfall and Agile

Waterfall is…
– Structured
– One big project
– A sequential process
– Suited for situations where change is uncommon
– Internal
– A process that requires clearly defined requirements upfront.

Agile is…
– Flexible
– Many small projects
– Highly collaborative
– Best for those who want continuous improvements
– Involves customers
– A process in which requirements are expected to evolve and change. It is constantly in development and constantly changing.

The debate

Many Waterfall worshipers blatantly point out that if Agile is a better way of working, why do some Agile projects still fail?

In this blog post, Eric Ries, author of The Lean Startup, tells a story of witnessing a product manager struggle to get results from his hard-working team. The amount of dedication and work put in by all team members using the Waterfall process only led to frustration and failure. Waterfall projects restrict the modification of requirements, therefore making it more challenging to adapt your project as you along. In his post, he illustrates how repetitive some tasks are, and how much time you can lose by using this method. His goal is to see this team transition from the Waterfall process to an Agile one. This would allow his team to spend more time collaborating together, and work on projects more flexibly.

However, this article by Smart Data Collective states that “Agile is not right for every project team and is absolutely not a silver bullet that will solve your organization’s delivery problems. In fact, if you are already struggling, trying to change to a new methodology might make things worse.” This is a bump in the road that teams may encounter if they are adopting a new methodology. Doing so would mean that they would need a clear plan of how to make this transition happen without worsening their situation.

We want to know:
– Which methodology does your organization use?
– If you use Waterfall, are you thinking about transitioning to Agile?

Related blog posts:
Agile Project Management and The Social PM
Agile strategies and alternatives
Agile Technologies and Their Characteristics
Agile approach: Practicing it with OneDesk
Agile Adoption Statistics 2012
Scrum Methodology vs. Agile Methodology
SDLC Methodologies: Agile or Waterfall?
Why Agile Fails

18 thoughts on “Waterfall vs. Agile”

  1. I think of the waterfall SDLC as crawling (i.e., executing the phases of the SDLC in a steady, logical and sequential manner) and the agile SDLC as running (i.e., executing these same phases in a rapid, random and concurrent manner). If you agree with that analogy then should also agree that trying to sprint before you know how to crawl is a bad idea. That’s just one of the problems I’ve seen with agile projects.

    1. Thanks for your insight Adrian. You are right, Agile projects move a lot faster. This is why in order for Agile projects to be successful, tight collaboration and communication as well as the right mindset and tools are essential.

  2. Good to know the statistics on the comparison. In this day and age PMs are definitely pressured to deliver faster, but are constrained by organizational paradigms to continue to “manage” a project instead of “leading” teams to deliver customer value. I find that often it is difficult for the PM to understand the core differences between Agile and Waterfall, in the basic objective of leading collaborative teams to successful projects. For any PM that understands the application of the concepts behind Agile and their application in the real world, these statistics are definitely not a surprise.

  3. Hi Yousaf, thanks for your insight. You are right – teams should take the time to properly understand the differences between methodologies before transitioning to them. Switching processes when the team is not ready can only lead to more challenges.

  4. Hi Kimberley, interesting post, thanks. I was wondering, with the charts showing the relative success of Agile and Waterfall, one of the criteria is finishing on budget. What I haven’t been able to work out yet is how to estimate how much an Agile project will cost up front. This seems contrary to the way Agile works, yet if the costs cannot be determined up front, then is it really possible to know if the project was successful from a budgetary perspective?

  5. What are the main factors we need to check ,for to decide which methodolgy to follow for SDLC.I have read many differences between agile and waterfall ,but still when it comes to the point of implementing ..it is tricky to understand .One of the user specified waterfall is for big projects ..infact i think big projects need agile instead of waterfall as developing big project can not be completley sequential..It is common to change requirements,designs ,cost and time frame for big projects whereas in other when it comes to small projects , it is more easier to follow sequential proccess instead iterating multiple times.
    Not only in SDLC but more common use of agitlity in every aspect of our lives ..is confusing me and making me to think ambigouos about the methodoly i need follow.

  6. Hi Aravind,

    You are right, choosing which methodology to follow for SDLC is not easy. The truth is, there is no “right” methodology for SDLC. The best methodology depends on your company. Before choosing a methodology, you need to understand what your company’s goals are, and how the people in your company work. Agile works best in small to medium sized organizations because it requires tight collaboration and a disciplined team that will stick to the process. Not all teams are willing to adapt to this type of work culture; it also requires a good leader. Agile is also possible with big teams, through the use of collaborative project management software. Teams would need to be trained on using them. With proper training, dedication and management, Agile can yield better results.

    Waterfall is easier to understand, especially if the team is inexperienced. It’s the best method to use if you are more concerned about quality than with going over budget or schedule.

    I hope this helped. Let us know if you have any more questions.

    Kim

  7. Pingback: Methodologies: Agile vs Scrum | Technology Blog

  8. Pingback: Waterfall vs. Agile | Agile | Scoop.it

  9. Pingback: Scrum methodology - a personal approach

  10. David Filipovic

    Hi Kimberley,

    Seeing how one of the criteria for a successful project was delivering a product with all of the planned features, do you think these statistics could be skewed by the fact that the feature set in agile is pretty fluid and subject to change?

  11. Should really read the following presentation presentation describing the RIGHT usage of the waterfall.
    You will be surprised about how different it is of everything that is said in the Agile cmmunity.
    https://goo.gl/kkCzbJ

    1. Hi Axel,
      Thank you for the resource. In your view, what is the biggest mistake or misconception about working in an Agile environment / community?

      1. Sry for late answer. I came coincidentally again on this site and saw yr post.

        First, I want to say that it seems that in waterfall-type methodologies there are a lot of bad practices. But that’s people, not the waterfall itself. Agile is right to emphasise more collaboration (vs throw-it-over-the wall-process… again a mistake made by ppl), flexibility and it uses some interesting concepts/techniques. I think that Agile is OK for specific projects and teams. I am not sure anyone can do Agile or any group of ppl can for a real team.

        Today, I have the feeling that many Agilits don’t really understand Agile or there is really a lot of confusion. The Agile world is rather chaotic in the minds (or blogs).

        I have serious concerns about the limited possibilities that Agile offers to project management. In the Agile frameworks no or little is said about Analysis and software engineering. Are Agile going to develop software without? Without Analysis you will have a lot of changes…not because of a real change (in business or in environment), but as corrections of bad decisions due to superficial insight. The focus of Agile is on developing features for end-users. In corporate IT environment, it’s about much more and many more aspects have to be taken into account (reusable components, services, shared data, security, disaster recovery, monitoring, functional integration, consistence, …) . I don’t believe that an approach designed based on principles which work for small teams is scalable. It is not for nothing that it is a hot debate. It is said that a good design emerges … what if it doesn’t? If code is changed continuously, this means more rework and every change is a risks, how can software development be faster? Over time (years), will Agile not lead to software chaos in larger companies? Why do Agilists impose their way of working or culture on Analysts, on PM, on stakeholders? Does this suit the business community and the management? What happens if an Agile team leaves a company (documentation?) ? It seems that the Agile community sees a company as a complex adaptive system (CAS). As a player in the market it probably is. But I am not sure that it is a CAS when we consider its internals. That’s a different level.

        Developing information/software systems are complex initiatives. My impression is that by focusing on the production of code, so simplifying the challenge, a lot of issues solved earlier by analysis and software engineering will be faced again. IMO, an important cause is the fact that analysts haven’t done their job well leading to frustration by the developers. It’s a factor, I think, but it’s all a bit more complex.

        Maybe Agile has some solutions/answers to some of these concerns. But these are my concerns today.
        It is also true that Agile is still evolving a lot.
        Best regards,

        PS the old URL to my presentation of the Waterfall doesn’t work.
        The new one is: https://goo.gl/bDI5Z1 80 slides… so there is some stuff 😉

Comments are closed.

Scroll to Top