Should we just stop developing software? Should we go back to Waterfall?
I know every person reading this could write a dozen pages full of suggestions for how to run a software team, but I really wish the author herself had spent some time suggesting what software engineers should be doing instead of "agile", because that, to me, would be infinitely more interesting.
Also, the rumblings of agile don't really point to anything to do with agile fundamentally, just the fact that people don't quite understand it or that management doesn't wholeheartedly embrace the mess.
"Agile meant that the team didn't really know what they were producing" - that is a Product Owner issue 100%.
So yeah, nothing's perfect but it's probably the least worse of the options we have!
Waterfall seems like a strawman to me. Has the tech industry ever used it? The first reference I could find for it was back in the 70s as what not to do. I don't think waterfall should be used as a defense to scrum.
As for alternatives, you can start with giving engineering teams autonomy and ownership of their work. Gergely Orosz has a good article on project management in tech.
http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
https://newsletter.pragmaticengineer.com/p/project-managemen...
Waterfall is in no way a "strawman", it's very real, and many shops who claim to be "agile" are still using it today, not to mention the near-ubiquity of its presence in software shops for years prior to agile taking over.
'… we need to accept the possibility that we will iterate during the development, perhaps within a given phase (eg reworking a design until it seems that it will give the required performance), or from one phase back to another (eg to correct a faulty design decision that, during construction, is exposed by a failure to be able to implement it). The biggest iteration is the one where we complete the development and, when we see what we have produced, we decide we need to start again and redefine the user requirements in the light of what we have produced. Such iterations happen in the real world and we wanted to accept this fact and put it in our model. Royce first formulated this idea in what he labelled the waterfall model … page 31
'The "oldest" process model is the waterfall model … This shows a similar progression from inception, through definition, the various stages of design, code, unit testing and integration to final acceptance. The fact that that progression is never smooth and monotonic is acknowledged by drawing little backward arrows suggesting iteration." page 39
1990 Strategies for Software Engineering: The Management of Risk and Quality
https://www.google.com/books/edition/Strategies_for_Software...
It did. That's objective fact. It was prevalent across the industry, that's also objective fact.
Seems like you deny that waterfall model.
Waterfall definitely existed. I've been at places that worked that way. I think Agile (and corruptions of) have replaced waterfall well enough that people no longer think it used to exist.
Ever wondered why so many Open Source projects deliver software vastly superior to commercial alternatives? It’s because in Open Source, non-competent folks don’t tell competent ones what to do.
Compared with the vast, vast array of software we both need and use, open source has failed. Precisely because there’s a gap between what the developer can envision and what is needed. Hence product owners. And a gap between the resources of time and money available and what a single developer can do in their spare time. Hence management.
PS: I also think you should re-examine your disdain for “burger flippers”. Even if it’s a low-autonomy job with much repetitive labor, there are aspects – like dealing with customers under pressure – which might break the average software developer. And people are much more than how they choose or are able to sell their labor. The general lesson here is that there’s usually a lot more to every job and worker than you think.
In many areas we are already doing waterfall, except it is a sin to call it that way and we must pretend we are doing agile.
Let me give you two examples: - Contractual requirements. If you have a contract with a customer to build X, no matter how much agile lingo you use, you are basically doing a waterfall. - Legal requirements. Same as above. For instance, there is very little flexibility in being GDPR compliant.