One adage that I've kept in mind for a few years is "trust makes the world go 'round".  By this I mean that there are many, many cases where mutual trust allows things to go much smoother and quicker, whereas a lack of trust creates extra work.  Trust greases the wheels, so to speak, while a lack of trust throws a wrench into them. 

There are many examples to which one can point: the old security-vs.-convenience tradeoff being probably the most obvious one.  A password prompt is an annoyance and slows you down, but is a necessity when a system can't automatically trust someone connecting to it.  In a much larger scale, you could say that our system of laws (and lawyers!) is an artifact of our lack of trust of each other.

But I thought I'd point out a more specific example.  Last fall a coworker and I took a class called "Agile Bootcamp: A Hybrid Scrum Approach" taught by Steve Davis.  The class itself was excellent, and I learned a lot about agile practices and ideals.

One of the goals of agile development is to streamline the development process.  Typically this involves reducing the amount of documentation and specification that is done.  Contrary to popular belief, agile proponents are not necessarily against documentation, but they are against unnecessary documentation.  In particular they are against documentation done too far in advance of implementation, because requirements change.

But there are multiple purposes for this documentation.  A design document not only tells a developer what to build, but it also formalizes to the product owner what they're getting.  This formalization is important in an environment where the product owner and the development team don't fully trust each other, such as exists when development of an application is outsourced to another company. 

I think that this aspect of the relationship between customer and development team is often overlooked by agile proponents.  But ironically, a large part of agile practices deal with formalizing the relationship more strongly, whether a contract is used or not.  While agile strongly encourages constant communication between the two parties, it also defines how that interaction should take place. 

You could say that the process replaces the contract - but only to a degree.  It doesn't provide the "guarantee" of a dollar figure or fixed set of deliverables.  You could say that that's a good thing, that that kind of guarantee is only illusory anyway.  Regardless, lack of a guarantee is an obstacle to trust, until the development team has proven its worth.

My company, a consulting company, has struggled with this dilemma since we started trying to use agile practices.  Historically, we have proposed a design up front for a fixed price, and accepted the risk of going over budget or past our due date.  This creates strong incentives for us to fully specify the design up front (since we are bound to the fixed price we estimate for it), and to limit changes to the requirements, or at least write in assumptions that they won't change, and charge if they do. 

In such a model, the fixed price satisfies the client, while the fixed set of requirements satisfies the development team.  The client's ideal world would be to pay a fixed price but be able to change what gets built at will, while the development team wants a fixed design but to charge on a time-and-materials basis.

In an agile model, the client pretty much determines priorities and can choose what gets built each iteration.  Detailed design documentation, if done at all, is deferred until right before implementation.  We can't specify a fixed design and price up front.  This makes agile development better suited to time-and-materials billing instead of fixed-price. 

More importantly though, it requires a lot of trust between both parties.  This trust makes agile better suited to internal development than outsourced development, because there's more trust there.  Trust is what allows agile development to be more efficient than waterfall development.

I've often wondered whether it would be possible to use a hybrid contract model, where the contract with the client is fixed price and with a fixed set of deliverables, but the project is run internally (by the consulting company) on an agile basis.  The contract would probably have to have some adjustments, but (key) the assumption of risk would be the same.   The consulting company would still have to estimate what it will take to build the entire feature set, and plan and price accordingly.  The client still gets a guarantee, but at a cost presumably built into the fixed price.  The consulting company gets to gain experience with agile methods, without losing work to its rivals.  You could say that this hybrid model is not truly "agile".  That's true.  But it might be a viable stepping stone to build trust between the two companies.