Re:Extremely uninterested (Score 1)

You bring up some very good points. However, just like any methodology, including XP, it doesn't cover all the bases. Having a good understanding with your customers about the costs of changing requirements late in the development cycle is a very good idea. I also like the point you make about how your customer never feels like the project is completed without a formal plan. While these are good points they do not cover all situations. For instance not every project can have a legal agreement like those for internal customers. (Those customers who reside within your company or organization) Secondly, you are misleading yourself in believing having a formal agreement will solve your problems. If someone who has a more agile or adaptable organization comes along and can accommodate those requirement changes then that organization or team will have a competitive advantage and soon your organization will start losing projects, because of your lack of agility. Another reason why you good reasons are misleading is that we are servants to the customers and what we want is to produce software that can actually be used. How would you handle a project whose requirements change through no fault of the customer, for instance the software needs to handle a change in regulation or a change in the competitive environment? The imposition of penalties and accusations of breaking the contract, if a contract is applicable, can do harm to the customer/vendor relationship. While the customer should understand that changes can cost more money. The developer must explore all avenues to reducing the cost to the changes this might include adopting XP. XP is just one effort in trying to be more adaptable to customers needs. Is it a silver bullet? No. However what you suggest to do is not applicable in all circumstances and can result in damaged customer relationship and software that does not do what people want it to do. Both you and those who propose XP and your suggestion need to keep trying.