Does Agile help you to know when to stop?

This week I had to teach two seminars - one on UML and one on agile methods. In the first seminar I was talking about use cases and requirements analysis, and I repeated the oft-heard remark that one of the biggest problems in software development is that "you never know when to stop." I think I mentioned it when talking about system context.

Then, during the agile seminar, we did a session of the Extreme Hour - where everybody builds his favorite coffee machine. An amazing number of inventive features came out for the coffee machines imagined by the group, ranging from battery power to background music to being mobile to being able to take outside. Many of the features came up during iterative sessions - that is, they weren't there in the beginning, but as people gained experience with the "system" they thought of more features.

At the end, one participant said, "Considering that problem of 'never knowing when to stop', agile development would make it worse - because it keeps eliciting more features as you go along." I must admit that it gave me pause to hear that, and I had to reflect a bit. This is what I think now:

The problem of "never knowing when to stop" will always be with us. It doesn't matter whether you are doing BDUF development or agile development or any other kind. But agile development frames the conversation about adding features in a better way. It ensures that the discussion between developer and client is immediate and continuous, including the discussion about the costs of adding features. This includes the techniques of optional scope contracts and the like, which give developers and customers a framework for discussion about features that doesn't become quickly antagonistic, but rather a real discussion with decisions that can be made together and based on facts. In a fixed-price contract, for example, you will quickly end up with an antagonistic discussion regarding "when to stop" where the developer is pushing to "stop earlier", and the customer is pushing to "stop later."

In other words, an agile approach to the problem of "never knowing when to stop" doesn't get rid of the problem or even make dealing with it any easier -- it just enables you to do a better job of dealing with it.