Agile vs waterfall project management
One of the things you will learn about on an agile project management course is the ‘waterfall method.’ Knowing how and why Agile was development can give you a better understanding of agile principles and values.
Before agile: the ‘waterfall method’
Prior to the introduction of agile software development methods, traditional waterfall methods were the de facto development process used across the software development industry. Waterfall project development is still used today in many modern industries (albeit with a few changes here and there).
Waterfall project management methods have undergone some revisions and improvement but are considered by many people to be somewhat dated when compared to the more modern agile methods.
Sequential phases
Waterfall methods take their name from the sequential nature of their development cycles. The first phase normally being requirements analysis, followed by design, followed by construction, followed by testing. The final phase marks the end of the project whereby the finished system is deployed and operated by users. When displayed on a chart, the development process very much resembles a waterfall, hence the name.
Because waterfall development is linear, software development naturally followed a ‘layered’ development cycle. One team would do their job before passing the software on to the next team who would layer their respective components onto what had already been built. It often took months and years for the final product to be delivered to clients. Any missing or broken components were only discovered long after the product had been deployed and development closed.
User uncertainty
In the early days of software development, waterfall-based projects were often plagued with delays and budget overruns.
One major factor which contributed to such delays was the false assumption that users knew what they wanted from the system. Making changes to a system to accommodate users’ changing needs was more expensive and time-consuming the later in the project these were implemented, as such many projects were late and over-budget.
That’s not to say though that waterfall methods aren’t still needed. They are used very successfully today on many projects – particularly those where users requirements can be clearly defined, or on projects (such as construction) whereby changes made late in the project are simply unfeasible.
The Agile Manifesto
In the early 90’s, small start-ups without limitless financial backing and time on their hands had to find a way to make software development more fluid and less costly. They slowly began to adopt agile policies into their development methods (although they had yet to be labeled as such).
It was only in 2001 that a small group of luminaries gathered to discuss their knowledge of software development management and create what is called the “Agile Manifesto.”
The manifesto created a rough guide for future software project development, underlining the principles the authors believed should be held paramount when approaching software development in the modern era.
