Using the Agile methodology to build custom software means a very different approach to the traditional waterfall model. In waterfall, fixed-price contracts were common because we had to define scope and specification at the start of the project. With an Agile project, this model cannot be effective. That is why you need an Agile software contract.

Customer collaboration over contract negotiation

The Agile Manifesto has four core values. One of them is that customer collaboration is valued over contract negotiation. The principle does not mean that there is no contract required, quite the contrary. It means that the Agile project contract you put in place for your custom software project needs to enable your project to function in an Agile way.

Consider how these core principles of Agile can impact how you think about your contract.

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Working software is the primary measure of progress.

These principles mean the contract should focus on how the work will be delivered, not what the final product will look like.

What to aim for in an Agile software contract.

1. Agile is built on collaboration and cooperation between the customer and the build team. The contract needs to be a shared risk/reward framework to encourage a win-win outcome.
   
2. The payment terms should be logical. For example, Suria Labs uses a time-based payment cycle. Here, the payment for each calendar month is on the 15th of each month thus each party accepts 50% of the risk. The supplier accepts the risk for the first 15 days, and the client for the second 15 days.
   
3. Change is an integral part of the Agile process, and so an Agile software project contract that references charging for changes won’t work.

Steps in getting the contract right.

1. Customer Engagement. This step should be a designated period for the supplier to carry out some preliminary work, sometimes called a Requirements Engineering Workshop. For example, client and supplier should work together to gather information about requirements, open lines of communication, test assumptions, build rough prototypes, and see if there is merit in the idea behind the project. The product vision should be an output of this work and be referenced in the contract. As an example, a startup without a clear vision of what they want to build can follow to process to generate a product backlog of estimated User Stories (note: link to User Story blog). As a result, there is a much clearer and more accurate understanding of the work and requirements than can be gained from an initial sales meeting. 
   
2. Time and effort. At the start of your project, (either at contract time or during your Customer Engagement),  agree on the number and type of team members, and their unit cost. For example, four developers at $x.xx and one designer at $y.yy. This method will allow you to define the ongoing monthly costs of the project.
   
3. Waypoints for the project. At the heart of Agile is the concept of iterative development. This means that after each sprint (usually one or two weeks in length) the client will have an updated application with the latest work incorporated which allows progress to be assessed. The sprint cycle is the most obvious waypoint to use. Tools like the burndown chart will also allow you to assess progress against the initial projections.
   
4. Lastly, the duration. How long will the engagement be? Your discussions should use estimates to agree on a starting duration for the contract given your understanding of the deliverables and the allocated resources.

Conclusion

If as a customer, you are using the contract to beat your development team over the head, then something has gone wrong with your project. A good Agile project means keeping honest communication at the core of the project, being open to necessary change that is highlighted through this communication, and using working, valuable software as your primary measure of success. A good Agile software contract encourages these behaviours.