First, the difficult answer: you do not have the power to intentionally change your client's behavior. The sooner you accept that, the better. Now for some more immediate, useful answers. They take the form of questions.

How do you know that agile methods will help your client? What benefits from agile methods do you believe your client needs? Have you clearly described those benefits to your client?

How do you know that your client wants the things you think he needs? Have you asked him whether he values those benefits you want him to have?

How motivated is your client to change his current behavior? What does he gain from doing things the way he does now? Have you asked him?

Now, a suggestion for you: read the book The New Strategic Selling for a model of how to understand the obstacles to a client "buying" your ideas. http://bit.ly/NYbBm

Good luck.

We ask them if they want to (1) control things or (2) get better software or (3) get the software sooner.

If they want any of these things, then we tell them about the Agile approach to get their deep involvement in planning each sprint.

If they don't want to control things or don't want to get their software sooner or don't want higher quality, we act in as Agile a way as we can in spite of them.

We try to do things in an Agile manner wether the customer wants to participate deeply or not. If they don't participate deeply, they don't get as many benefits from the Agile methods. We still get benefits from using Agile methods.

In addition to all answers I can share my simple idea (not tried yet) - while negotiating price (assuming fixed price contract) try to put it this way: if we go waterfall the price is X + 40%, if we go agile the price is X. Client would definitely be curious why it is so, and there you go - first sign of involvement. Then explain in details how it works and why it's cheaper. Make sure you got real client support going agile, so put organizational stuff in contract (ie. client updating backlog, available on sprint planning and so on).

what you think?

You start by convincing them to change the way they run ONE of their projects, and prove the benefits.

I think therein lies part of the problem. It sounds like you're trying to apply a single solution (Agile) to a very complex problem. Agile may not be applicable to ALL of their projects. Agile works in selected instances, but it can't be translated to all industry (and I realize most here are software/IT PM's, sorry.)

You have to explain the benefits, explain how their increased role is going to benefit the product, and then you have to deliver. Do that with a pilot project and the rest should be easy.

You shouldn't be concerned with the client's methodology. Your focus should be helping the client meet their goals.

Communicate to the client in the language they understand. Then run your projects internally however you want to. If you want to run agile, have someone internal be the product owner and make the calls on features.

Asking the client to adapt to your practices always feels, to them, that you are trying to unload work on them. The same thing happens in Waterfall when you ask them to write, read, contribute to or sign-off on a big spec. They'll never read it. It won't protect you if you deliver to spec but its not what they wanted. And, to them, asking them to be deeply involved in a spec feels like you want them to do your work.

You are the expert. You need to understand what they want, then deliver it.

show bottom-line benefits:

• direct control over priorities and scheduling
• participation early and often in the design
• direct control over budgets as reflected by per-feature costs
• frequent useful software versions
• ability to halt the process at any iteration

[the latter two can be very important for those unsure of what they want and/or on tight budgets]

but make sure that the clients understand they have ongoing responsibilities; they don't just 'dictate and wait' as with waterfall/all-or-nothing methodologies

I always give client a choice, if he make a wrong one - means I probably don't want to work with him - I set the price very high.

While not every one has this comfort, it is important to give a choice and not be pushy, say what are advantages and hope client will do the right choice ;) I also explain the process (we use Scrum) and a lot of clients really like idea.

Common arguments we use:

Agile as competitive advantage. This is good for clients that are loosing the market or those on very competitive markets):

• Time to market - you can make first release before others will finish specification and contract
• Being flexible - you get user feedback, can respond to it and give new features in 2-3 weeks not months, you can react to market change, competitors new products etc
• Reduced risk - with agile you can step out of the project in any moment

Agile as money saver. This is good for scrooges.

• For money that you would pay to lawyers for creating contracts and to analysts for creating specification you can already buy a couple of sprints
• Most of projects fail, if you are going to fail with agile you will know after few sprints not after a year, you will lose some money but less then if project fails after a year.
• In IT projects there is always risk involved. I have to estimate, if I overestimate - you paid too much, if I underestimate - project is a problem, so I'll look for ways to push it out - eg. reduce quality (via @paulklipp)

Control & Communication & Transparency. This is good for people who like to control details.

• at every moment client can check what is progress on the project and what is estimated time of delivery
• communication - your clients understands choices, can modify requirements to boost business value, reduce time to market - client is in control of details, team can give him suggestions like - this will speed up, this will make it more usable, client can make wise choices on the run, he don't need to predict every detail

Quality:

Clients don't understands what quality means. Quality can be understood various ways. Like nice design or low number of defects. Very rarely what client thinks (unless technical one) is code quality, which most often has no value to the clients. Talk rather about being flexible.

Google use it, MS use it, Yahoo use it, your client's favorite company use it. Business people like brands :)

Don't just throw this into his face. Ask him what are his expectations, listen and choice those which fits.

The answer depends on context.

If for instance the client has asked you to demonstrate or explain the benefits of agile your task is made easier by their willingness to listen. However if you are effectively 'cold calling' and try to push agile on a prospective or current client, that is a harder task.

The first thing I do when asked to explain the benefits of agile is to explain that Agile does not mean faster, and Agile does not mean better. Agile means having the ability to be adapt quickly.

I go on to explain that XP techniques can help improve quality of delivery regardless of the project management approach.

Finally I round up by demonstrating (using a simple visual aid) the basic tenet of agile that the released product is something the customer actually wants and will use and is still relevant to their market space as opposed to the product set in stone at a point in time that no longer meets their real requirements.