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, 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.
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 document how it works once it is done or while being done. 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 focuses on the Minimum Viable Product (MVP) where as waterfall favors the total vision. Agile seeks in each launch to be a release that gives value. 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 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)
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 waterfalls at much faster rate with an MVP 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
Stephen is a double threat holding both SAP business objects certified architect as well as being a certified IBM DB2 Database Developer. read More…