Writing a functional specification divides the project between the consumers (The business) and the producers (The Development Team). The developers say they will only develop that which is written in the spec and the users want the app to work even though it might not be specifically written in the spec. This causes a tension between the business users and the development team. This tension is normally "managed" using a change control process. From experience, users will cram as much as they can into the specification because they know changing it at a later date will be so painful. The result is "scope bloat" - A whole load of requirements that the business do not really want. Unfortunately, decisions about the project will be significantly influenced by the scope bloat features even to the detriment of the core requirements. This is one of the advantages of a business value driven approach, that it focuses the effort on the important features.
Agile takes an alternative approach. The developers say "We will deliver good stuff. You just tell us what you want for the next iteration." We will decide what to deliver in the following iteration just before we start it. It means that there is no need for a change control process. Hence more harmony within the extended project team.
After all, the users are learning about the business problem just in the same way that the developers are. So of course it is naturally that they will change their minds as they get to understand more about the problem.
Posted by chrismatts at June 6, 2004 4:43 PM