When I was in college in the 90s, they actually taught waterfall as a baseline to compare other methodologies. Agile hadn't appeared yet, but it was obvious the

When I was in college in the 90s, they actually taught waterfall as a baseline to compare other methodologies. Agile hadn't appeared yet, but it was obvious then that waterfall's main issue was the inability to change and adapt to a changing business climate. In other words, once you worked out a 3 year dev plan, it was set in stone, even if the business or industry had changed (and needed the software to change). The alternative was to make shorter iterations. Our professor called this "Cinnamon Bun". Instead of one big waterfall, covering the entire project, you'd break the project up into chunks, but apply the waterfall steps to each chunk. Planning, Analysis, Design, Implementation, Maintenance were the steps. Each chunk would vary, but we typically broke it up into month or two chunks. Of course you'd need planning and analysis up front to figure out the best way to divide the chunks. When Agile/Scrum came out, its proponents compared it to the shortcomings of Waterfall, which was disingenuous because pure waterfall had been largely abandoned by at least the mid 90s, and probably sooner. As an aside, One important step in waterfall was Maintenance. This seems missing in current methodologies as a formal step. If you write successful software, the maintenance phase is 80-90% of the softwares lifecycle. Understanding this equates to the understanding that writing maintainable code is one of the most important things a development team can do.