Contracting for Agile Software Projects, Part 1

April 22, 2009 by Peter Stevens

As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. Although the Agile Manifesto values customer collaboration above contracts, contracts are necessary when working with external suppliers. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. Which contract forms are best for agile software development projects?

This is the first of two articles. In this article, we’ll look at the purpose and contents of a contract and some criteria for evaluating agile contracts. Next week, we’ll look at contracting alternatives for Scrum software projects and examine their strengths and weaknesses.

What is the purpose of a contract?

Contracts set the basic playing rules for the project. In theory, they are freely entered by both parties to create optimal conditions for successfully completing the project. In practice, contracts are often seen as competitive games, in which the objective is to place the other party at a disadvantage, especially if things go badly. Very large companies and governments often have standard conditions which have to be accepted en bloc as a pre-requisite to doing business with them. These conditions are seldom fair, so a reasonable project outcome depends heavily on a good relationship with the actual customer and avoiding recourse to the contract or the law. (The Agile Manifesto is right in this point: customer relationships are more important than written contracts!)

Even negotiated contracts do not always strive for a win-win situation, so you may need the help of experts. However from the customer perspective, contracts produce no added value. They are a waste product, so the effort spent negotiating & producing them should be minimized.

A contract apportions risk and reflects trust between the parties. What happens if something goes wrong? Who pays how much if the project is more difficult than expected? Who benefits if the project is finished earlier than planned?

The wrong playing rules can be detrimental to the success of the project. Bad rules can lead to unrealistic prices, time frames or functional expectations. Win-lose games are detrimental to project success. Quality most often suffers. Do you want the ‘A-Team’ or the ‘B-Team’ working on your project? Think carefully about how much pressure you put on the supplier.

How to evaluate contract forms

Commercial contracts can take many forms. What are the contract alternatives that are suitable for agile development projects? For any contract, I would look at:

• How is the contract structured? What are the basic rules for delivering scope and invoicing revenue?.
• How does it apportion Risk and Reward between customer and supplier?
• How does it handle changes in requirements?
• What model of customer relationship does it foster: competitive (my win is your loss), cooperative (win-win), indifferent (I don’t care-you lose) or dependent (heads-I-win-tails-you lose)?

If I did not draft the contract, I would also look for traps - contact negotiation can be competitive game. The question is what do you do if you find one? Try to get it taken out, or accept it and move on? Let's just call this a 'business decision'.

What information should a contract include?

The more trust that exists between customer and supplier, the less you will need to write down. In my experience, there are a couple of points which belong in every contract:

1. Objectives of the project and of the cooperation between the companies. This follows pretty directly from the elevator pitch and product mission.
2. An outline of the project structure - Scrum process, key roles and any differences from Scrum which apply.
3. Key Personnel - who is responsible at the operational and escalation levels and what is required of these people?
4. Payment and billing, including any bonus and penalty clauses
5. Early and normal termination.
6. “Legal Details.” Depending on local law and legal customs, you may need to limit civil liability, specify venue, ensure severability (that portions of the contract are remain in effect, even if parts of the contract are found invalid) or include other text to prevent various legal bad things from happening. Sample or reference contracts from your jurisdiction can be helpful (and are cheaper than a lawyer!).

Do you need to include the scope in the contract? Often it is present (at least in the government contracts I’ve had the privilege signing, it was included by law), but fixing the contract in scope also renders scope inflexible. If possible, it is better to specify how you will manage the scope (e.g. Product Backlog, Sprint contract), but operational details should be left to the project team.

Points 2, 3, 4 and 5 determine the playing rules for your project. If you get these right, you will have the foundation for a good project. But what are the best rules? There are at least a half dozen different kinds of contract, from time and materials to fixed price, fixed scope.

Next week, I will look at the different contract types and how compatible they are with Scrum and agile projects.

Permalink