It seemed like such a good idea after that disastrous release using a waterfall development model. Move to agile - 3 week iterations, content for the iteration fixed, etc. But then the release date gets set and management decides that it's not cost effective to do an extra build between the last two iterations.
As the Program Manager, you agree. It seems simple. But then all the last minute changes come in. Feedback from the beta panicks the sponsor. The content changes, and expands - pretty soon you're in the middle of a giant 6-month 'iteration', which for all intents and purposes is back to waterfall.
Been there. Done that. It ain't pretty.
Sometimes it's really the right thing to do - you really do have the final content and that last build will put you two days over into another iteration. But most often the content grows, and pretty soon you're trapped in that place where you're facing a big QA cycle and there's just that one last thing...so how do you draw the line?
My advice is this: if it really does seem like the best idea, don't exactly agree to a 'final' iteration. Agree to one extended iteration - but put an end date on it (like 6 weeks). Freeze the content the way you always do. Schedule a follow-on iteration that can be patched in if there are truly emergency fixes; and if it turns out that there are just a lot of changes you can just use that standard follow-on iteration as the next one. When you propose this, remind the sponsors of all the reasons you went with Agile in the first place and what happens with waterfall. Because everyone will truly think that there will be no changes, you'll probably have no trouble getting them to agree to this up front. If they're right and there are no changes (or few enough to patch in with a final iteration) then life is good. On the other hand, if the world explodes and you have change after change, you've already got the vehicle, agreement, and expectation of getting back on the Agile wagon and can proceed without sliding down that very steep and slippery slope.