"Before the software was even finished, PoS software was able to interact with the API and insurances had sent out millions of cards." Yes. There are hard con

"Before the software was even finished, PoS software was able to interact with the API and insurances had sent out millions of cards." Yes. There are hard constraints in many projects. If you know exactly up front what you need, you do not need Agile approaches to handle the uncertainty. However, there is plenty of uncertainty to be managed behind this API. "Agile is far more suited for constantly changing environments, where you also can just break support for any third parties depending on your API. But obviously, that’s not really quality software when every software depending on yours has to be changed every few years." One doesn't have to change an API to evolve the software. Old school HTML and HTTP from 1992 still works on an evolving web. "But obviously, that’s not really quality software when every software depending on yours has to be changed every few years." APIs can be made to be backward compatible or versioned as they evolve. Again, you presume the people asking for the software know exactly what they want. IF they do, then you are fine. It is very rare in practice except for simple or well-understood predictable domains. If the stakeholders do not know or agree on what they want (most of the time), something like Agile is appropriate to manage change. Most APIs evolve a lot as parties learn more about the problem space, but this does not necessarily mean older versions automatically break. This really has little to do with Agile vs. Waterfall, it has more to do with the design decisions made for evolvability.