"We value customer collaboration over contract negotiation." -- The Agile Manifesto
Contracts for software development have historically included language that specifically defines the software being developed. This protects the buyer from paying for an asset that does not serve its business needs, the seller from requirements drift or expansion, and allows both parties to agree to duration and cost. Traditional development contracts also stipulate the process by which the software is to be developed and tested, and how changes will be accommodated. Since the way something is produced has direct bearing on the quality of what gets produced, specifying the process protects the buyer from slipshod work practices, and gives the seller a formal framework to control the development lifecycle. The parties are trading a long-dated asset for a series of short-dated cash flows; being specific about the work being produced and the means of production is a means of protecting each party's economic interests throughout.
But with Agile becoming more and more widespread, contracts that stipulate requirements, team composition and change control processes lock both buyer and seller into a commercial arrangement that is an encumbrance (requiring constant amendment to accommodate changes) and may actually interfere with delivery. Agile development requires more flexible contracting. So it comes little surprise that a core tenet of the Agile manifesto is that people involved in developing software should constructively collaborate with one another to deliver a valuable business asset, not conform to a strict protocol that defines allowable behaviours.
The rigidity of traditional contracts has led firms in the Agile development business to experiment with looser contractual language. In principle, this makes sense. Agile teams deliver more frequently, so the lag between the buyer's cash and the seller's delivery isn't as great as it is with traditional software development. Frequent showcases and deliveries improve trust and confidence between buyer in seller in ways that can't be codified in the language of a contract. The benefit of looser language is that as teams learn more about the actual business needs and technical complexity of what they are developing, they have more freedom to act (and react) as the situation warrants. There should also be limited downside. Even if the contract is vague, a buyer won't pay if she doesn't like what the seller has produced, and a seller will suspend work if he has an unwilling or incompetent buyer. The people involved have maximum leeway to get stuff done and they'll let each other know in the most direct means possible when they're not happy.
In place of precisely defined language, it isn't uncommon to see development contracts that capture none of the intent whatsoever, and define only a supply of an unspecified number of people for an indefinite period of time. If the understanding ex-contract is that the seller is there to develop software for a particular purpose in a particular manner, the contract is, in theory, at best a formality and at worst takes too much time. If the development work is treated as R&D rather than a capital investment, doing this doesn't flaunt accounting practices (which require strict definition of capital work). And if one party is disappointed with another during development, they'll make that abundantly clear by suspending performance until they are happy. This is the triumph of the desire to get stuff done over the formality of contract law.
"That is, while there is value in the items on the right, we value the items on the left more."
But contracts do matter.
A contract expresses the value each party places in the other and the respect they have for one another. The preamble language defines who the parties are or think they are as an acknowledgement of the strengths that each bring to the relationship: they are disruptors ("re-imagining the classroom for the 21st century"), or market leaders ("the nation's largest provider of financial services to retirees"), or specialists ("the leading provider of software development services to municipal governments in the tri-state area"). This underscores goals of the buyer (the disruptor is buying an innovative solution; the market leader wants cost efficiencies) and the capability of the seller (technical, process or subject matter expertise) and why the two parties want to work together. In the contract, if the buyer is just a business no different from any other, and the seller is just a provider of people, the relationship will eventually come to reflect this, too.
A contract communicates the outcome the parties are working toward. If the buyer wants an asset, they are committing to developing an asset in conjunction with a partner, and both buyer and seller are drivers in achieving that goal. If the buyer wants only to rent capacity from the seller, the seller will be a passenger in the buyer's goals.
A contract defines a bond between two organizations, a bond that is meant to be durable in good times and in bad. The more closely twined buyer and seller, the more likely they are to resolve their differences and difficulties. The more disposable a relationship, the more likely one party will dispense with the other when greener pastures beckon.
We don't want contracts that are ignorant of the need for flexibility. But convenience erodes commitment: flexibility achieved through ambiguity undermines a sense of partnership. It is better to achieve flexibility through provisions that define the parties, define the mission, and define a bond. This creates a commitment to the principles of a relationship.
Contracts exist between companies; relationships exist among people. A relationship will always trump what's written in a contract. But people come and go, and relationships are constantly tested. A contract easily exited undermines the commitment of a relationship. Good contracts are not an encumbrance to delivery: they strengthen the commercial ecosystem through which delivery happens.
