Except that Waterfall was never really advocated: https://davesquared.net/2008/01/contentious-myth-of-waterfal...
It was conceived as a straw man which was being dissed so vigorously that people started believing it was real.
It was conceived as a straw man which was being dissed so vigorously that people started believing it was real.
And Agile has it's fault and it has become filled with consultants, buzzwords and all kinds of things but early days when I built an internal system used in factories for a large company. The old ways of building and documenting software there was pretty much waterfall and there was a lot of middle-management, reporting, architects, documenting etc.
I was a part of a pretty young team + one offshore team in India (that was not great but not bad either) and we had a great boss who fought for us when we wanted to develop using pretty standard Scrum instead and we had a great product owner who immediately got what we were after and had great domain knowledge.
That project went sooo much better than previous ones and even if there were a lot of fighting and escalations in the beginning the whole concept of "Just call into our demo's we have every three weeks and see what we are developing and then give feedback" was like a revelation for some would be users of the system or owners of processes we implemented.
I've heard countless people advocate for waterfall. I was formally taught waterfall years ago. It was how many people approached development for a long time, and how some people still approach it today.
Here's just one concrete example I could find in seconds - an article from 2006 advocating for its benefits https://www.techrepublic.com/article/understanding-the-pros-....
Waterfall is really how you manage other large construction projects like building a house or a bridge. So it is not completely crazy to think you can also develop software that way. It took many failures to realize software demanded a different approach.
It doesn't work this way because software development is the process of figuring out the actual requirements and a good design. You don't have to follow an agile methodology to acheive a successful project, but you do have to have feedback loops that reduce the risk of wasted effort.
In the engineering analogy, I like to tell people that the compiler is the builder. All coding is an exercise in architecture and engineering that produces a detailed design (the code).
In my experience very few people truly understands why engineering is something expensive at its core, and it's usually this particular lack of understanding that ironically ends up making making things even more expensive and produces worse value-for-money, and so the vicious cycle continues.
Then their beautiful 5 year late 2000 page specification slams head first into the realities of computers and the project immediately becomes quagmired. It's basically the Soviet model of computer programming, where you try to make all of the design decisions from the top but the people at the top don't have the whole picture and can't make good decisions and the scope is way too large for mere mortals to learn enough to make said decisions.
So much this.
I've been in the industry for about 30 years, and I've never once seen a place that used a methodology that could be called "waterfall" as described by many agile proponents.
It was always a "no true scotsman" issue. If it didn't work, it was because we didn't adhere to it and didn't gather the requirements completely enough. So, sure, waterfall never existed in the sense that it never worked out, but it certainly existed in the sense that it was pursued to the tune of countless man hours and countless dollars.
It was also the only process I learned in college ('94) and was strongly advocated in my classes.
Most attacks from the agile community probably are coming from a place of never having actually seen or practiced the real thing however. For example it does flow backwards at times, it's not the nonsense straight line process that gets straw-manned sometimes.
This is rather my point. In "waterfall" shops I've worked at, the way it has never worked is that the application is completely designed up front, then implemented. The reality is that there has always been iteration involved, and there has always been refining and modification of design, and etc.
The only thing (aside from "ceremonies") I see agile bringing that didn't exist in my experiences with "waterfall" is the notion of bringing the customer in as a constant part of the development process -- which is a welcome addition.
The rest of Agile that I see can be thought of as refinements to waterfall, not as something entirely different.
Yes, it was horrible.
Yes, it got worse when they added the mandatory omnibus all-hands standup scheduled for 8:45-9:00 every morning, that always somehow lasted until at least 9:30, because everyone was continually justifying their existence.
And it was redundant with the spreadsheets that recorded the time spent on any particular task, down to the second.
we were just so blind back then that we thought we could predict the future. When faced with direct evidence that things weren't going according to plan, or that the commercial landscape had changed, we stubbornly went back to our Gantt charts and insisted that it just couldn't be so.
so we just never got anything done..until some genius decided we had to meet every morning and schedule everything in 2 week intervals.