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 know what each is fundamentally, so let us just dive into the main differences.
We will examine agile vs waterfall by the following dimensions
- Value Delivered
- Risk
- Cost of Change
- Transparency during the Project Life Cycle
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 overall design and test cases associated. Agile development front loads changes and expects that the payoff is richly rewarded by lack of rework later. Agile only limit is that you cannot interrupt the tasks in progress (active sprint) but with small batch cycles opens the window of change quite frequently before the final product is released. Each Increment is an opportunity to readdress business value and change if that is what is needed.
Agile estimation is re-coursed after each sprint and therefore beats the cone of uncertainty as it progresses
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. The golden triangle of Cost/Scope vs Timeline vs Quality is better managed under the frequent ship-able increments than a monolithic software release.
Waterfall is documentation intensive where agile tends to favor loose documentation.
Waterfall front loads the documentation of requirements whereas 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) whereas 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 is 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, during the active sprint.
A waterfall project might have an increased workload in a release if the client realizes that halfway into the project that he missed a critical functionality. This functionality is critical to the project launching successfully. Many projects either expand the scope or will be pronounced DOA (dead on arrival).
Agile factors in the velocity of a team and the number of story points per sprint. This means the sprint is always re-calibrated and scope creep is managed. If a new story must enter the sprint then the equivalent story points must be removed to keep the same total story points to keep the velocity
I view that agile is v2.0 of the waterfall model. it uses the best parts a framework 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 paperwork 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
