processes like this should not be treated as one size fit all t-shirt.
documents might go over certain size. document templates are always under review (by quallity team) to make sure they hold appropriate level of details. temaplate might change based on lessons learnt and reviews.
from project, product and program management view point, the whole thing is a series of iterations. they only see the dates and deliverables (to include customer support team as well) but to system  engineers and solution architects the process  is iteration + refactorying (that's what they end up doing in iterations) and from dev view point it is all of those plus XP.
if you look at how internal sw is released, i.e. 5 as main 5.1 as a target goal for certain date, 5.1.1 to hold certain features and 5.1.1.1a to hold fixes parallel to 5.1.1, refactorying is surely happening to introduce either patches or internal releases with major fixes or reshaping things to match new stuff (which was not visible at the time) - I agree should not happen, but it does
this is reallity and in simple terms, "whatever works for you" , but the important thing is that the big iteration sw dev process should deliver whatever was signed off in the original scorecard, and down there you do XP, you stay over the weekend or over night but it has to be delivered