> "You're going to do agile .... and this list of features will be ready on September 20th."
Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then.
We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.
What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect.
When there's a time constraint one has to be able to winnow out the real must-haves from everything else.
It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"