And that's the problem of Agile in a nutshell - you open up for not meeting schedules because you have to be agile, allowing changes. So you either deliver an unfinished product or go over time. Seriously so. The correlation between not meeting deadlines with a finished product and Agile is so high it converges towards 1. Really.
You can't have something for nothing, and in Agile you pay for your gains by not being able to deliver a full product on time. If upper management aren't informed of this, they need to be.
Interesting. Because when we were in modified waterfall, we had to allow changes or the clients would not be happy. Change happens in custom Enterprise software development. If you are working in a "product" shop, bless you. You are probably much happier than me. I have to deal with users who have conflicting ideas of how they do their own jobs. In fact, they have imaginary ideas about the business requirements which we find out half way through is wrong. Change is our environment. Management wants us to be able to react to changing user requirements quickly, document & cost them, etc. With the modified waterfall, there was a huge bureacracy to do that, and people would argue if it was a "clarification", "discovered requirement", "scope increase", etc.
Which again points to an important point about any process you follow: it must match your reality. If you are working in products, you have the luxury to aim for a relatively well defined set of requirements for a given release. You could probably do well from modified waterfall or some sort of iterative waterfall. For us, management's #1 priority is to make our clients happy and give them custom developed software that meets their needs, even if the clients don't even understand their needs. For us, agile is a better fit. For you, something else.