Making software development contracts Agile

Even when managed well, risks can remain when taking the agile approach:

• Having less detailed requirements might encourage supplier innovation, but can equally lead to ambiguity and misinterpretation.
• Evidential issues might arise from the collaborative approach, such as determining which party is responsible for a defect or delay. Was a failure of the supplier to achieve a critical requirement consequence of the priority given to that requirement by the customer, or if the customer has members of its personnel on the development team, was the defect caused by the customer's or the supplier's personnel?
• Repeatedly adding incomplete or unaccepted items from a sprint back into the Product Backlog for remedial work may result in cost overruns and overall timetable slippage.

For public sector customers such as government departments, a specific concern may arise from the supplier being unable to accurately price Agile projects at the outset.

This is due to the flexibility of the approach and not having detailed customer requirements, which in turn means the supplier might only be able to provide a loose estimate. This may make it difficult for the customer to properly form its business case, which is a key requirement for public sector procurement.

What to include in your Agile development contract?

Thankfully, there are a number of measures that can be taken to mitigate against these risks:

A right to terminate the contract early can help in avoiding the potential for increased project costs or delays, and incentivise the supplier to perform properly.

For example, the customer should seek to have the right to terminate after every Sprint, but may negotiate this with the supplier so that the customer only exercises this right in respect of critical requirements or due to cost blowout.

Any right to terminate should include a right for the customer to take what has been delivered (together with any necessary licences) to a replacement supplier.

Costs for remedial work

Ensure that the supplier bears the cost for any undelivered or unaccepted requirements that go back into the Product Backlog after a Sprint. This will help incentivise the supplier to ensure it delivers successfully under each Sprint.

While some developers might argue that it's not in the spirit of an Agile project, customers should set clear performance targets and goals for each Sprint, such as the minimum number of requirements that must be successfully delivered.

The contract might also link payments to the achievement of these performance targets (eg, by reducing the instalment to be invoiced at the end of each Sprint on a pro rata basis if the supplier fails to deliver all of the requirements, or withholding a certain percentage of the overall project fee until the project as a whole has been successfully completed).

Compensate for the use of non-technical "user stories" to define the requirements by ensuring that the acceptance criteria applying to each Sprint are described in detail

Project roles and responsibilities

Ensure that the roles and responsibilities of the project team are clearly defined in the contract.

Selection of appropriately skilled personnel (on both sides) will be critical to the success of the Agile approach, and the contract should therefore include a process for determining how the development team and other key personnel will be selected and – in the case of the supplier's personnel – retained for the duration of the project.

Customers should also be mindful of creating evidential issues in establishing a warranty claim or protection under the supplier's IP indemnity if the customer's own personnel have had a significant role on the development team.

The authors, Steve Nightingale, Philip Wood, Andrew Matangi, Amy Ryburn and Allan Yeoman are partners and associates at Buddle Findlay Lawyers, New Zealand