>That’s part of what waterfall advocates for. Write a spec, and decompose to tasks until you can implement each piece in code.

That's what agile advocates for too. The difference is purely in how much spec you write before you start implementing.

Waterfall says specify the whole milestone up front before developing. Agile says create the minimum viable spec before implementing and then getting back to iterating on the spec again straight after putting it into a customer's hands.

Waterfall doesnt really get a bad rap it doesnt deserve. The longer those feedback loops are the more scope you have for fucking up and not dealing with it quickly enough.

I don’t think this whole distinction between waterfall and agile really exists. They are more like caricatures of what really happens. You have always had leader who could guide a project in a reasonable way, plan as much as necessary, respond to changes and keep everything on track. And you have people who did the opposite. There are plenty of agile teams that refuse to respond to changes because “the sprint is already planned” which then causes other teams to get stuck waiting for the changes they need. or you have the next 8 sprints planned out in detail with no way to make changes.

In the end you there is project management that can keep a project on track while also being able to adapt to change and others that aren’t able to do so and choose to hide behind some bureaucratic process. Has always existed and will keep existing no matter how you call it.

>The difference is purely in how much spec you write before you start implementing.

Ah, and therein lies the problem.

I’ve seen companies frequently elect “none at all” as the right amount of spec to write.

I’d rather have far too many specs than none.