… 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 worked at one Agile place they had all their sprints and milestones in a Gantt Chart waterfall. They also did big design up front and a lot of process. They had do all kind agile and scrum training, but it was the most process heavy place I worked.
Im currently trying to steer a product team to have this kind of process. They are working with an ancient piece of software that is slowly being replaced. However, we need to replace piece by piece while the main app is still being maintained because of law and workflow changes. This is why i want them to set the requirements and designs up front a bit so we can make a good analysis of it before development starts so no technical difficulties or questions arise mid development!
However, nothing is set in stone and after each small piece ( aka after each sprint ) we have our review and product owners and stakeholders see what we have made and can chime in, causing us sometimes to pivot what we were making.
Best of both worlds!
Rewrites are great. You have a specification that is so defined it is literally code.
When it’s blue sky, it’s harder. Plans will be wrong. The users don’t understand really what they need or want. It all ends up evolving. Anything with a GUI is worse because users/customers need (want) things moved about, re-themed, with no regard to what’s below. Best to nail them to mock up designs they signed off on. Same with API interfaces. If they signed off on the design, you can then point out “spec change” and get more time/money. It’s more about ass covering than using the outcome or process.
Agreed. Depending in what branch or situation youre in you need handle appropriately and cover your arse but also make it work. If i was to work on a timed project, and the project is set to not make the deadline due to spec changes i will report that ahead of tine to cover the teams arses, but at least we can pivot and deliver something that will be useful and up to spec depending on the feedback :)
Correct! Hence why i said it all depends on the product, the team, the time, money, project, …
Many factors that decide on how to tackle things and the problems :)
… 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
Exactly!
I worked at one Agile place they had all their sprints and milestones in a Gantt Chart waterfall. They also did big design up front and a lot of process. They had do all kind agile and scrum training, but it was the most process heavy place I worked.
Im currently trying to steer a product team to have this kind of process. They are working with an ancient piece of software that is slowly being replaced. However, we need to replace piece by piece while the main app is still being maintained because of law and workflow changes. This is why i want them to set the requirements and designs up front a bit so we can make a good analysis of it before development starts so no technical difficulties or questions arise mid development! However, nothing is set in stone and after each small piece ( aka after each sprint ) we have our review and product owners and stakeholders see what we have made and can chime in, causing us sometimes to pivot what we were making.
Best of both worlds!
Rewrites are great. You have a specification that is so defined it is literally code.
When it’s blue sky, it’s harder. Plans will be wrong. The users don’t understand really what they need or want. It all ends up evolving. Anything with a GUI is worse because users/customers need (want) things moved about, re-themed, with no regard to what’s below. Best to nail them to mock up designs they signed off on. Same with API interfaces. If they signed off on the design, you can then point out “spec change” and get more time/money. It’s more about ass covering than using the outcome or process.
Agreed. Depending in what branch or situation youre in you need handle appropriately and cover your arse but also make it work. If i was to work on a timed project, and the project is set to not make the deadline due to spec changes i will report that ahead of tine to cover the teams arses, but at least we can pivot and deliver something that will be useful and up to spec depending on the feedback :)
I don’t think there is a way that always works.
It’s not always possible to get a clear spec and do big design up front in R&D. The whole point can be to work out what can be done and how.
Correct! Hence why i said it all depends on the product, the team, the time, money, project, …
Many factors that decide on how to tackle things and the problems :)