At a certain point all software needs to be maintained. Interfaces change, the environment it operates in changes, etc. You can handle that with a level-of-effo

At a certain point all software needs to be maintained. Interfaces change, the environment it operates in changes, etc. You can handle that with a level-of-effort support contract. At what point do you say "it's done!" have the development team move out, and have the support people come in? You could say "requirements are satisfied", is the threshold but those always change on a project. You need to predict what you need in the future. No one is good at that, but the fact that some may be lucky does not imply that it's possible. Doing it right in a schedule based environment means contract renegotiation. This could be expensive and many times its easier for the customer to bypass management and convince the engineers to take on more scope for free. This happens all the time, project managers need to be vigilant! But vigilance does not build value, it just creates avenues for conflict. Regardless of what your methodology is, every successful project will become a "unknown deadline, flexible features" product at some point in its life-cycle. Why are we bifurcating that stage at an arbitrary point based on faulty assumptions made months and years in the past? What agile does is it moves the arbitrary bifurcation point to t=0 and avoids classes of zero-sum customer-management-worker conflicts.