Irrespective of what the Agile Manifesto says (“Customer Collaboration over Contract Negotiation”) we do require a signed contract for ANY medium to large software outsourcing engagements – and that includes agile projects.

Why? Because when there is a commercial arrangement between two parties for delivery of any service where a significant amount of financial transaction is involved, there needs to be a clear agreement on:

1. What is the service that is going to be delivered and what will be the charges for those services?
2. What happens when things go wrong?
3. Do's and Don’ts of how the interaction will happen

So, any contract for agile project outsourcing also needs to answer these points. But, how will an agile contract be different from a traditional software outsourcing contract?

This post is based on…
Major part of what follows comes from the whitepaper Agile Contract Premier by Tom Arbogast, Craig Larman, and Bas Vodde. I recommend that you read it.

I have also used some ideas from the following posts:

• Agile contracts – Alistair Cockburn
• Contracting Agile Projects – Jens Coldewey (Cutter Consortium)
• Agile Contracts – Allan Kelly (InfoQ)

Let us see what these practitioners have recommended.

Is it possible to have Fixed-Price, Fixed-Scope (FPFS) agile contract?

Yes, it is possible but it should be avoided.

• Requirement specification that is signed off is almost never what is actually needed
• In an effort to deliver something within the constraints of price and scope, suppliers will often degrade the quality of their work – reduced code quality, do less testing etc.
• Price include large risk contingency – this premium is usually hidden in the effort estimate

As a result, the customer may not get what they want and supplier may lose out because of changing requirement.

How can the supplier make such project work?

• Use people with experience of the domain and the technology to estimate the effort
• Clearly lay out the acceptance definition or the definition of “done”
• Ensure that new requirements only displace existing requirements if they are of equal effort
• Decide how additional requirement will be charged

FPFS contracts are common where there is low level of trust between both parties. This may be a starting point in the engagement and it the project is successful more flexible contracts can follow.

What are the options available for Variable-Price, Variable-Scope contracts?

Such contract normally starts with a Master Services Agreement (MSA) which is more like a rate card. The rate may be for people deployed, cost of each iteration, function point or story point delivered etc.

Since we are talking about variable-scope, there will not be any detailed definition of scope. However, there may be an overall cap to the total price of the contract.

Some form of an order may be released for executing the next iteration or next couple of iterations which will have a clearer definition of scope or backlog.

To cover the risk the contract may be terminated after completion of any iteration – agreed termination charges may have to be paid.

Can you have a completely transparent payment model?

Yes, if you follow Toyota. It is called the target cost contract. They follow this five step process:

1. In collaboration between customer and supplier, identify, analyze, and estimate all possible project requirements.
2. In collaboration, estimate the cost of change or scope increase during the project.
3. From these two elements, establish the target cost.
4. Calculate target profit, based on target cost (for example, 15% of target cost).
5. Share all details and results with customer.

The idea is to have a trusting relationship where pain and gain can be shared by having a mechanism to adjust the actual cost based on the changing scope.

How do you protect against things going bad?

This is clearly the domain of the contract lawyers. They are supposed to ensure that contracts are drafted in such a way that suitable clauses are in place favoring their clients.

It is essential that non-lawyers involved in negotiating the contract understand the lawyers point of view.

However, one of the key premises of agile methodology is that the project risk is reduced through iterations and early delivery. So, it is strongly recommended that lawyers working on such contracts study and understand how agile method reduces risk.

This can help in significantly simplifying the contract.

Successful projects happen not because of the contract but because of many other things including collaboration, transparency, and trust. There are many natural roadblocks in the path of a successful project delivery – the contract should take care not to add any more roadblocks.

After all under normal circumstances everyone’s number one priority is to deliver a successful project. (There are situations where some people may want the project to fail.)