Okay, so what's the alternative? I read most of this article and scanned the rest, but could not find any proposal.
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.
Similar to you. There were several hints that the author didn't really understand software. The problem with waterfall wasn't that you had to do tasks in order, it was that you needed to know mostly everything in advance to get rid of issues at design time so they didn't bite you during coding.
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.
Every time you have a "Gather Requirements/"Design"/"Develop"/"Test"/"Deploy" set of stages, you're using waterfall. Note the absence of "collect feedback from customers".
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.
It needs to be part of all of them, but you can't do it meaningfully in any one of those steps, because you don't have a working product to actually show the customer until the end.
'… 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
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.
One alternative would be to move the vast majority of managers where they belong - flipping burgers in McDonald’s - and instead spend this money on people with some idea of how computers work. The workflow will evolve naturally.
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.
Open source has succeeded at creating common infrastructure, where technical vision matters most. Sometimes.
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.
I absolutely don’t have any disdain for entry-level restaurant employees. As you say, it’s a perfectly fine job. But it’s also a job that a typical medium-level manager should be qualified enough for, as opposed to working as a plumber, a doctor, or any job related to software.
This is a good point. The question isn't whether Agile is perfect (it is certainly not), but whether it's the best option we've got. If it is, then we should continue to use it. If it's not, then we should switch. I would be really interested in learning what the next attempt at a better methodology looks like.
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.
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.