… 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.
Agile has its uses, but like everything you need a bit of both. You need a bit of both waterfall and agile.
Example : you need to have your requirements before development, yes. But how far do you go in your requirements? If i were to make all the requirements for my current project ill still be busy in 3 years and will have to redo bits due to law and workflows changing. however , we need requirements to start development. We need to know what we need to make and what general direction it will be heading to a make correct software/code design.
Agile also teaches you about feedback loops, which even with waterfall, you need to have to know that what youre developing is still up to spec with what the product owner is expecting. So even with waterfall, deliver features in parts or sit together at least once every x weeks to see if youre still good with the code/look/design.
Pure agile is bullshit, but so is pure waterfall. Anything that isnt a mix is bullshit and in the end, it all depends on the project, the team and the time/money constraints.
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
… 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.
Agile has its uses, but like everything you need a bit of both. You need a bit of both waterfall and agile.
Example : you need to have your requirements before development, yes. But how far do you go in your requirements? If i were to make all the requirements for my current project ill still be busy in 3 years and will have to redo bits due to law and workflows changing. however , we need requirements to start development. We need to know what we need to make and what general direction it will be heading to a make correct software/code design.
Agile also teaches you about feedback loops, which even with waterfall, you need to have to know that what youre developing is still up to spec with what the product owner is expecting. So even with waterfall, deliver features in parts or sit together at least once every x weeks to see if youre still good with the code/look/design.
Pure agile is bullshit, but so is pure waterfall. Anything that isnt a mix is bullshit and in the end, it all depends on the project, the team and the time/money constraints.
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