![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://fry.gs/pictrs/image/c6832070-8625-4688-b9e5-5d519541e092.png)
… I cannot count the number of times at my different workplaces where we had an agile process, dailies and everything else of the agile BS for projects which where either trivial or not solvable. No worries, the managers, product owners and agile coaches made money and felt good, we developers went for greener pastures…
Agile is a scam, nothing they do is based on any facts and when you challenge agile coaches / other people which profit it is always ‘I believe’ or ‘proven by anecdote’.
Combine this with the low quality of people in the average software projects and you have a receipt for failure.
Writing the requirements first at least forces people to think trough a project (even if only superficial), so I am not surprised the success rates for this projects goes up.
Good points, and I mostly agree with you, especially with feedback loops!
Still, I never argued for waterfall. This is a false dichotomy which - again - comes from the agile BS crowd. The waterfall UML diagram upfront, model driven and other attempts of the 90s/early 20s were and are BS, which was obvious for most of us developers, even back then.
Very obviously requirements can change because of various reasons, things sometimes have to be tried out etc. I keep my point, that there has to exist requirements and a plan first, so one can actually find meaningful feedback loops, incorporate feedback meaningfully and understand what needs to be adapted/changed and what ripple effects some changes will have.
Call it an iterative process with a focus on understanding/learning. I refuse to call this in any way agile. :-P