Q:

Does late have any meaning in Agile methodologies?

This came out of some of the answers and comments on another question (this one).
I've worked primarily with waterfall projects and while I've worked on ad-hoc projects that have taken on agile behaviours and have read a fair bit about agile, I'd say I've never worked on a "proper" agile project.
My question is does the concept of "late" have any meaning in agile, if so then what?
My reasoning is that with agile you have no upfront plan and you have no detailed requirements at the outset.  You may have a high level goal in mind and a notional date attached to it but both may change (potentially massively) and neither are certain.
So if you don't know exactly what you're going to deliver basically until you deliver it and the user accepts it, and if you don't have a schedule beyond the next sprint, how could you ever be late in any way that actually has meaning?
(Obviously I understand that a sprint might overrun but I'm talking about beyond that.)
Just to be clear I'm (personally) happy with the assumption that on time waterfall projects (even relatively large ones) are possible based on the fact I've seen them and been involved in them - they're not easy or common even but they are possible.  
This isn't about knocking agile, it's about me understanding it.  I've always seen the benefit of agile as nothing to do with deadlines or budgets (or rather only indirectly), it's to do with scope - agile delivers closer to what is really important rather than what the project team think is important before they've seen anything.

A:

I disagree that an Agile project has no upfront plan. 
My experience is that the business analysts have spent a fair amount of time working in design meetings with customers and developers to come up with a detailed list of achievable requirements that are presented as user stories. These are then broken down into tasks with suitable estimates attached by experienced developers.
Once the most important tasks have been identified at the start of the sprint/iteration then coding can begin. This selection process determines the meaning of the iteration in the overall project ("We're building the login process"). Various memebers of the team get on with the various tasks necessary to make that user story happen. 
At the end of the iteration all the user stories for that iteration should be complete, or you're late. Equally, development should be able to stop at the end of each iteration and the product released. It may not be complete in terms of all user stories, but those user stories that were requested in the iteration are complete and the product can work to those limits.

A:

"late" in an agile methodology means the same thing it means in a waterfall methodology: the estimates were wrong, the scope was too big for the allotted time, unexpected difficulties appeared, the customer wasn't responsive enough, the programmers got lazy, the machines crashed, your dog ate my bytecode, etc.
you learn from it and adjust for the next iteration
the difference is that this can happen every 2-4 weeks, so the lessons get learned and the process gets adjusted rapidly

A:

Yes, but it will only take 1 month to know you won't hit your 9-month-mythical-final-project-due-date instead of 9. 
Your reasoning is based on the assumption that upfront plans and detailed requirements for large projects are possible. Not sure there is a lot of evidence to support that. Maybe all the horror stories are just anecdotal? Any developer would love to work with complete and never changing specifications that the client fully agrees with and understands.

