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.