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. It's all a matter of guesses, no matter how well polished. This is something we simply must accept, and from that standpoint find another way to work, a way in which the lateness issue is made much less important. A change of perspective.
The way to do that is making continuous deliveries of working software, with an option of stopping the project when the client is satisfied. And that is what agile is all about. A clever way of 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 by able 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.
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 by able 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.
No comments:
Post a Comment
What are your comments? I'd love to hear 'em, so don't be shy now :-) If you want to get in touch with me directly just drop me a mail.