Does late have any meaning in Agile methodologies?

Question

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.

Answer 1

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.

Answer 2

"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

Answer 3

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.

Answer 4

Anytime you make a commitment of some kind, you run the risk of being late. That applies to agile as well.

But we know you cannot predict the future, and we know the customer will constantly change his mind, and we agree that is a good thing. If we accept that, we must also accept that all commitments are pretty much always wrong, which, in turn, makes the question about lateness easy to answer: We are always wrong (to early or to late). It's all a matter of guesses, no matter how well polished. Toss a coin.

This is something we as developers simply must accept, and from that standpoint try to find another way to work, a way in which the lateness issue is made much less important. A change of perspective. I think the way to do that is focusing on delivering working software as soon a possible, with an option of quitting when the customer is satisfied.

And that is what agile is all about. A clever way to managing this uncomfortable notion that lateness is a fact and we simply have to deal with it the best we can.

For example, you are late when you fail to deliver on the commitments you did at the beginning of the current iteration. This is expected and you should learn from this and adapt your process so you are less likely to fail in the next iteration. The best way to handle this is to keep iterations as small as possible.

For multi iteration planning, aka release planning, you use the velocity calculated from the completed iterations and extrapolate the data to a predict a future release date. I recommend James Shores' article or my own (shorter) for more details about this. Note that it's never a solid commitment though and more of a "we are 80% certain that we will complete the next features by that date". This can (sort of) result in you being late, but the commitment is only a probability, not a fact.

Now par this with the basic promise of agile that you should always ready to release working software, feature complete or not. This gives the customer the freedom to stop development when he thinks the system is good enough, which can happen a lot sooner than anticipated. It also encourages taking the project in new directions based on real feedback from the latest iteration.

The above points should be more then enough for any customer to be in full control of the development, and I hope that answers the question about lateness in agile methods.

Answer 5

There are two types of "late" in Agile SCRUM >

1. Carryover - Stories not "Done" at the end of a sprint, developers "commit" to getting a PBI done, so when it's not done, it can be considered carry.

2. Roadmap - Assuming your org has a roadmap and assuming it has dates, if the major deliverables for those dates are missed, that can be considered "late".