"What do you mean?"
"Looks like you put the right foot into the left shoe and vice versa."
"Yeah, looks like you're right. That's why they were hurting so badly."
"Aren't you switching them?"
"No, I'm late, I gotta get going now."
One of the strongest advantages of iterative development is that the concept of iteration leads also to the concept of checkpoint. The moment you release an intermediate milestone is also a moment to think and verify if you're going in the right direction. That's also a moment where you take a breath and think instead of just doing things.
Put in another way, iteration doesn't mean repetition. Splitting the project time line in iterations means that there should be fixed moment reserved to approaching the project from another angle. SCRUM makes this "what's the biggest slowing factor of the project?" question at the center of the project lead on a daily basis. Long lasting waterfall projects normally place this question far too late.
If you are in an agile or iterative project, and there's no difference, or perceived change from iteration n to iteration n+1, this is generally a bad smell. Normally it means that this is not an agile project or, more precisely, that it's not an adaptive one. Checkpoints are probably used only to track the elapsed effort and delays, and to re-adapt estimates. A more pervasive, SCRUM like, survey might lead instead to a different way of doing certain things, or to a suggestion about how to improve them.
It's just a larger scale application of the tuning methodology: test (iterate), measure (finish the iteration), diagnose (the iteration meeting), and correct (plan for the next iteration). If the iterations borders are blurry, you have a lot less test information, if you're not having a meeting, you're probably not getting all the information you need for a good diagnose, if you never stop and plan for a change, you'll never improve. If you keep on postponing needed changes, just because you are too busy, ... you'll always be.