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.
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.
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:
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'.
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:
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.