Extreme programming and clients
I work for an Agile company (not strictly XP, but still applicable) and our client base is exclusively government organizations. Once they saw the results of the agile process at work, even those who had waterfall requirements for documentation were more than happy to continue to take advantage of the agile process.
And, yes, I agree with vfilby. Your customers should care about results, not how you achieve them.
source to share
If your team has achieved great results thanks to a proven track record, then companies want a successful outcome. If the opposite is true, then only those who follow the tracks are interested.
There is an odd case where a client wants to follow a particular practice. As a seasoned web developer outsourcing a project to an outside firm or potential client who has heard that XP is doing well but has no real knowledge or experience with it. In the first, the savvy consumer will know what they want, and if you don't provide these services, they will go elsewhere. If you try to fake it, they will find out and be very unhappy. Later, it doesn't matter as long as they get good results and believe that it was their own wisdom that got them off the ground.
Either way, it matters.
Now begins my diatribe, which so far has inspired many anger:
Could you jeopardize your successful actions just for the client? If you're steadfast in favor of XP, sell it! If they want you to use a methodology that you strongly disagree with. Tell them that. If you can't come to a consensus, there shouldn't be any deals.
Will I tell the baker which grain to use? How hot is it to have ovens? Of course not. If I say I want poppy seeds on buns, I don't care how to put them there while they are there. Dp Do I pick a baker based on his methods or how damn tasty the bread is? Giving the non-programmer a hint on how to make their craft is just plain bad.
If you are trying to extol the virtues of XP, then be up front and state the benefits and ROI. Show them why they are better off in terms of developer efficiency and defect reduction. If you are not working for programmers, you are an expert, take reign and give advice.
If your team does a great job of XP and has great results, you should have no problem selling any potential client in your practice. Results matter to customers; as long as you can prove that you consistently produce high quality products within the time frame, you will have no problem selling your methodology. (with a few exceptions that absolutely require a waterfall).
source to share
I think this is probably less convincing than for clients to adopt agile development methods, especially XP, as they are much more popular now. Customers who have had a positive experience with agile teams in the past are more likely to buy these methods. It's probably easier for a smaller client, or a client with less issue to adopt XP if they have issues with it. With a skeptical client, I suggest starting with a little confidence and self-confidence. And make sure you deliver to your promises!
source to share
Pretty much everyone else seems to be interpreting your question in the context in which you are working, or working with an ISV, creating custom software for a client. Is this a situation?
If your question was something like that the company is likely to adopt XP, then I would say that a company that has been burned in the past is spending too much time developing developer documentation and designing for reuse just to to dismiss it all as a great waste of time and effort.
source to share
The client should accept iterative delivery with fixed time, fixed resources, fixed quality (it works up to 100%), and little volume change per iteration.
Much more common, however, is that they want to capture time, resources, quality, and scope.
The type of client that is likely to support XP methods is one that already understands the advantages and disadvantages of the software production system provided by XP.
source to share