[lelanthran]

> Most likely both the customer and you would be happier if you were able to iterate with them rather than building the thing they thought they would want however many months back. (And while it may be harder to set up that kind of contract, it's absolutely possible)

Possible? Sure. Just like it's possible that I could win the national lottery.

In practice, multiple companies bid for contracts, and all of the bids have to be of the form "Deliver $X in $Y months for $Z dollars".

No company is going to accept "Choose us, and we'll work until you're happy with the product or you run out of money, whichever comes first".

Agile doesn't work where there's competition for the project. It can't, because the buyer of that project cannot evaluate "we'll work until your money runs out" against the other bids that state "$X in $Y months for $Z dollars".

Agile works well for internal teams that are sheltered from having to provide competitive bids.

[webmaven]

One approach is value-based contracts: "we'll work with you and charge X% of the value we deliver."

[lelanthran]

> One approach is value-based contracts: "we'll work with you and charge X% of the value we deliver."

Which still loses to the other bidders who say "$X in $Y months for $Z dollars".

[webmaven]

No, not necessarily. It depends on how often and badly the org has been burned on past project failures.

Typically, the intermediate step is to tie some compensation (such as a bonus) to a particular metric, but why not just go whole hog?

Even if X% is projected to be larger than $Z (and in fact, the better the project succeeds, the larger the %X total ends up being, but you can cap it, or make the % progressive up to a point and regressive above it), the advantage for both client and vendor being aligned on the upside is considerable.