I have been programming since 1977, getting into the weeds with the Heathkit educational series on analog and digital technology including machine and assembler programming. I have also programmed in Fortran, FORTH, C++, Java, PL/SQL and TSQL. I have used declarative tools such as Oracle Forms. I have worked on large (100 people) and small projects (3 people) using waterfall and agile.
One of the problems of waterfall is that big consulting firms get involved and feel like their value is determined by the weight/number of pages of documentation so it takes months to produce the bloated fluff that adds no value. I have seen large waterfall projects fail because of this. One of the issues I see with agile is that many shops use the word agile to justify bad practices. An example is to emphasize "the conversation" and ignore the written documentation. When that happens you have one person who knows a specific part of the app and it takes a new person weeks to figure out the original requirements so they can fix a bug, add an enhancement or include new functionality. This may include many hours with the subject matter expert and the original developer, if they are still around. In this case the original application was delivered faster because no one had to consider other parts of the database or wordsmith the requirements. After the task is completed, no one goes back to their notes to document what they did because they are on to the next task.
I have been working with databases for over 3 decades. The agile concept of small things done quickly can result in some really bad database designs that are hard to understand and expand and lead to a lot of data integrity issues. I attribute this to the vision of a developer who has insight into a small portion of the application so he creates tables and columns without considering if they already exist or how else they may be used. Often teams do not have a database designer to review the impact of changes.
For those who may not know or who have not read the manifesto recently, I leave you with this, emphasis from my perspective:
The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
© 2001-2019 Agile Manifesto Authors
This declaration may be freely copied in any form, but only in its entirety through this notice.