Compare Agile and Waterfall methodologies, Which is better, What are the Pros and Cons?


A practitioner point of view on building software using  Agile vs Waterfall methodologies.

I have been a practitioner of software development for 20+ years.   I have aided my previous company to be certified Capability Maturity Model (CMM) Level 3 in 1998.  I have not only studied methodologies for approaching software development but I have also been able to successfully complete many projects using various methodologies like waterfall and rapid prototyping/extreme programming, which coincidentally looks like it evolved into agile.  I first read the agile manifesto in 2007 and really appreciated the values and spirit of the manifesto.

There are many papers that cover what each methodology is and I am going to assume that we all know what they are so lets just dive into the main differences.

Agile is very tolerant of requirement changes but waterfall is resistant especially prior to a release.  Waterfall will ask the new requirement (change) to be documented then pushed back into the design to see the impact to over all design and test cases associated.  Agile development front loads changes and expects that the payoff is richly rewarded by lack of rework later.

Agile estimation is re-coursed after each sprint and therefore beats the cone of uncertainty as it progresses but waterfall only gets one chance to estimate and it does not compensate very well for bugs which varies from one team to another.  Estimations are not law and when they are created there are many unknowns.  Users tend to hold on to these as gospel and over the life of the project it is never re calibrated but instead is share and other plans and timelines become dependent on these estimates.

Agile does just in time requirements but Waterfall attempts to predefine all the requirements.  We can quickly see that the longer that project last then the more obsolete the software will become at the time of release.  It too complex to be knowing the future state at the time of writing the requirements as things are changing daily.

Waterfall is documentation intensive where agile tends to favor loose documentation.  Waterfall front loads the documentation of requirements where as agile will dive into functional code immediately and use story point style documents on who is doing what and how it is expected to work.  The user acceptance is always a good idea to be part of a user story. Developers tend to appreciate this since the job is programming  and not novel writing.  This does not mean that operational support teams can survive on poorly documented systems.

Agile favors daily conversation with the product owner where waterfall relies on the requirements documentation defined. 

Agile encourages teams of 3-9 people where waterfall will work with any size team which can be potentially large.

Agile focuses on the Minimum Viable Product (MVP) where as waterfall favors the total vision.  Agile seeks in each launch of ship-able code to be a release that gives value, the increment.  These releases are frequent in comparison to waterfall and the duration are much shorter.  There are huge ramifications of this philosophy, here are my key ones:

Agile has a compounding effect of adding value to the business with each release.  Waterfall has one major release that comes months after the first meeting.

Agile promotes development at the speed of business change.  The business can change direction before a waterfall project is released to production for usage.

Agile allows re-coursing the project direction while in flight. Waterfall encourages the team to finish using the plans that the project started with.  Agile is not tied to the feature set and can stop at any point of interest but waterfall are feature set driven as prescribed by the requirements document.

Agile promotes more a greater learning curve of each release.  The team learns the most during requirement gathering and product delivery.  The more you do it, the more you learn.

Agile preventing forced injection of new scope.  A waterfall project might have an increased workload in a release if the client realizes that half way into the project that he missed a critical functionality.  This functionality is critical to the project launching successfully. Many project either expand the scope or will be pronounced DOA (dead on arrival).  Agile factors in the velocity of a team and the number of hours/story points per sprint.  This means the sprint is always re-calibrated and scope creep is managed.

I view that agile is v2.0 of the waterfall model.  it uses the best parts a frame work to approach building software using design, test and build strategies but adapted to the value proposition of the business.  I would dare to say that agile is pigging backing the waterfall and the next generation of reducing useless paper work to get better working software.  Agile is like doing many smaller casual cascading iterations of design, build and testing at much faster rate with an MVP (usable software) in mind.  Its evolution and inevitably you will use techniques of both. I dare any developer to say they are going to build software and never did a design session, or used Test driven design then coded. That is principles waterfall have done for decades.  Just some food for thought.

Stephen Choo Quan