I have been working in Agile since 2017 in several projects.
And I would like to note here a couple of moments from real experience through the eyes of the developer with technical role in project.
Hope it will be helpful for you.
"The main thing is to do functional increment to show some new features to the customer." - typical situation in Agile team.
The above statement is killing thing for developers and DevOps infrastructure!
You will ask why it so? Let me give some background.
In one of the projects, I was fired for the normal implementation of the developed service due to the fact that I managed to work it out in detail, but instead I had to do it quickly and not so much detail, since the customer already wants another features. The technical director supported me and wanted to keep me in the project, but the situation did not allow him.
In the current project, I see how the Agile methodology is trying to work on a big and complex backend project and this leads to poor-quality implementation with problems:
large amount of stupid meetings with not clear meaning, involving different area specialists
incomplete specs due to frequent architecture changes.
low-level coding by developers because new functionality needed even yesterday.
Taking above written situation in account - had an opinion that Agile might be useful for a project with an already working website... because:
Someone has already developed this website normally by Waterfall and it worked even before the attempt to implement Agile.
Users (business) can constructively evaluate the features of an already working website and such user stories could be really taken into account for Agile backlog.
In all other cases, Agile will provoke a quick search for some pilot functionality (most probably with outsourcing), its quick adaptation and refinement for the project.
And here need to note what is IMPORTANT for developer:
participation in the project so that what is written will work for an adequate time and will not be thrown out due to spontaneous changes in architecture.
good specifications and the responsibility of analysts and architects for what is written and drawn in the documentation.
Waterfall is a more structured project management method and does not create so called strange "FLEXIBILITY" which totally destroys normal process of development engineering. In my experience, this "flexibility" to changes leads to fly to Venus instead of Moon - when fly had to be to Moon.
And one more point - often we can read that Agile is better because it allows client to see the functionality faster and correct specs if needed. But again this frequent correction will cost a LOT as about time and about development resources! And maybe this correction NOT SO needed and even NOT NEED at all.
It is better to spend time(by Waterfall) and give client first full release and ask for complex feedback - rather than do small frequent releases (by Agile) and start chaos of incomplete improvement.
Yes, maybe in the start of project - client, architect and analytics does not know in details how to write all functionality in specs. But it is critically important to write and freeze changes of specs for some adequate time to obtain first normal release. So better spend time in the beginning for good specs(Waterfall) and get runnable result based on these specs, rather that seat on long meetings day by day(Agile) and try to satisfy all the desires of the client in taste and color.
For good, detailed specs and not everyday changing architecture - I'm as developer will say "Thank you!".
If you have what to say about the topic and want to give negative rating - please feel free to write your comments to understand your opinion. Otherwise it is not serious and it is not clear why you vote negatively.
And of course If you like this article, please vote UP - this will support me to write more such posts with real experience!
Cheers!