How do you charge your customer in a project using agile methodology?
Per hour? Then a great deal of trust has to been established before the project.
Per iteration? There's gonna be a lot of budget decisions, which can take time.
Per project? How can you do that when you don't know the scope? The very essence of agile is to not write a big upfront design/specification.
You charge your customer on the base of the terms defined by your contract that will be slightly different from a traditional fixed bid contract. Let's call that an Agile contract.
Some options are discussed by Alistair Cockburn in Agile contracts.
Another great resource is 10 Contracts for your next Agile Software Project by Peter Stevens.
Mary Poppendieck also has great material on this topic. See agilecontracts, agilecontractsworkshop, Contracts Excerpt From Lean Software Development, Lean Contracts. More here.
Short answer is, you won't. There are a few services companies that are making headway doing it, but it is a difficult path. Your ability to sell the methodology and convince the customer you can deliver will be high.
Customers don't want to risk paying for a solution that will never be delivered.
Typical approaches to this problem are to put "will not exceed" cost. However, if you can't control scope, you are the one taking all of the risk.
In short, you are looking for customers that would have signed up for T&M (time and materials) contracts before Agile became the latest fad (I'm part of that fad, but it is just one in a long line of development processes. Aspects of it will continue to grow and some permutation of it will have a different name in a few years).
If your customer has already bought into the use of an agile methodology, then you have a reasonable framework for negotiating price per iteration. For example, you know:
That's a lot more evidence on which to base pricing decisions than is available for most fixed price contracts.
If the agile methodology is purely an internal development process that doesn't involve the customer, then it's unlikely to have much effect on the pricing negotiation between the supplier and the customer. There is an argument that says that a process that doesn't involve the customer in setting scope and expectations at least once per iteration isn't agile at all.
Regarding Mark's comment, there is a very common pricing model based around fixed price contracts with loosely defined scope and optimistic schedules. A common outcome is that both supplier and customer find that their initial optimism was misplaced. Both end up negotiating from weak positions over the things that really matter to them, and both end up unhappy.
Some of the techniques that work well in managing this type of contract are very similar to those used in managing agile contracts (frequent delivery, horse-trading on scope, priorities & price, frank communication, ...) the main difference is that these aren't built into the original agreement, and the contract may not be flexible enough to accommodate all of them.
My 2c as a non-agile practitioner...in a quest to know more...
If you are doing a specific project for a customer, you will need to know the scope of the project to provide a cost and a timescale. The cost of producing this scope of work is more often than not part of the discovery of the project, you either take a hit on this to get the work or charge for this (explicitly or implicitly) In this case, a project cost can be worked out and agreed. Im this case the project is usually broken up into various stages.
Although agile may be iterative and not require a full specification; a goal, at least is certainly required. There must be some form of basic specification/requirement. It may be that you need to break the project up into smaller goals and apply costs accordingly.
The iterations I suspect are more to do with the development methodoology, ie to achieve the goals?
If there is not enough specification to produce a definitively accurate cost, I would say that a "estimate" should be given but work should be charged at an hourly rate as I would assume that there would be greater changes in the decisions made on the project over each iteration.
