While working on Fixed price model, software vendors would analyse  the requirements upfront and commit to a price with the customer.  Many a times, the customer fixes a price and the committed bidder gets the project.  

The uncertainties involved in the software development makes this model a flawed one.   As per the popular and well researched  Cone of Uncertainty,  the initial estimate done at the beginning of the software project could be +/- 400%

off-mark than the actual calculated at the end.   In order to mitigate these uncertain risks, companies participating in these contracts have to add a lot of unscientific buffer to accommodate them.

Projects applying Agile methodologies is supposed to have a flux associated with them. The scope could change any time and this needs to be accommodated in the contract and this is not easy. This is one of the reasons for Fixed price contracts not being popular in Agile projects. Even though there are several case studies of application on Agile projects but at the end of the day, the constraints imposed by Fixed Price model might actually destroy the agility.

Photo Courtesy: http://www.construx.com/Page.aspx?cid=1648

Time & Material(T & M) as the name implies is supposed to work well for Agile software development as it has no restriction on price or scope. The customer can keep paying as long as the value is getting delivered. However, my observation has been that this model works  well in an established trustworthy environment. 

Several experiments have been made in creating contracts specifically suited to Agile environments.  Some of them include:

1. Phased Delivery
2. Capacity Based
3. Value Based

Phased Delivery contracts divides the entire project life cycle into multiple different phases. A goal is set for each phase and funds are released based on the delivery. The goal could be the number of user stories to be delivered in each phase providing additional quality related info.

Capacity based contracts would provide X number of people for the project  and no scope related delivery constraints are signed.

I am also envisioning Value Based Delivery contract, and I am not sure if some one has experimented with this.  I feel that, either a $ value or some unit could be assigned to Epics or to user stories theme.  As and when this gets delivered, proportionate amount of fund could be released. Again, quality related matrices could be an additional parameter in the contract. 

An Agile practitioner  has put together a list of 10 styles on Agile contracts . check this link out for more details.

Summary
I strongly believe that  Trust and Contract are inversely proportional to each other. That is, as long as we have less trust, we need more contracts.

source: http://agileworld.blogspot.com/2011/11/agile-contracts.html