We’re Agile – How Do We Do Contracts?
As Agile developers we know that change happens during the lifetime of a project. We’re happy about change – it means that either the client has a deeper understanding of the problem, or the requirements are adapting to changes in the real world. Either way, the end result will be better software! We have processes in place to manage change on a week-to-week basis; managing change at a contract level can be more complicated.
Signing a contract is about controlling risk. We want to balance the risk that we don’t complete the work within budget (client risk) with the risk that the project changes significantly and the workload increases (developer risk). Agile prioritises exploration – we don’t attempt to get a detailed paper version of the software before we begin the contract. If that’s the case, how do we sign a traditional contract with detailed budget estimates?
Agile contracts exist but require a lot of faith on the part of the client. In a simple Agile contract, the two parties would agree to begin work and continue until the client is happy that the software is complete. In an ideal world this works well; the client and developer have the same aim of high quality software delivered for the minimum cost. This isn’t far from the truth – any serious business knows that happy customers are more important than squeezing extra billable hours. We don’t think it’s reasonable to assume this level of trust from the client.
Standard Contracting Models
So how about standard contract models? Let’s look at the two extremes:
- Fixed Price Contract: This model looks ideal for the client; who doesn’t like knowing how much work will cost up front? In practice however, this rarely works as passing all the risk onto the developer encourages them to be change-averse. Any new requirement stretches the original contract and so must be controlled tightly. If we believe that change is positive, then fixed price contracts are an unnecessary constraint.
- Time & Materials: A plain time and materials contract puts the risk on the clients side. If a contract runs late, the client must either end the contract (perhaps paying penalties for termination of contract) or continue paying for more work. By not giving estimates or plans, the client has a hard time measuring progress. How does the client know if the contract is going to be successful?
Our Shared-Risk Contracting Model
We start with a basic time and materials type contract, but make changes to give the client full control over the process. This results in a more balanced distribution of project risk between ourselves and the client. Specifically:
We start with a breadth first discussion of the project. We don’t attempt to build a detailed requirements list before the project begins – we don’t believe this is useful. Instead, we aim to record enough detail to provide a good estimate of cost and timeline to the client. This is fluid during the project – if the client changes the high level requirements we’ll discuss how this affects the estimate.
We provide milestones to the client. We focus on delivering working software to the client throughout the project. Agile aims to have the client get value from the software as early as possible. We use this early delivery to help the client measure progress. By comparing our timelines and estimates to the real world progress, the client knows how we’re doing.
We remove any termination clauses. If the client isn’t satisfied with the progress or work they can end the relationship at any point. We’ll deliver all software completed along with an invoice for the work done – no extra charges.
These three changes let us apply Agile processes to make the best software possible, without exposing the client to unnecessary risk.