Making software development contracts Agile

Software development projects delivered using 'Agile' methodology (rather than the more traditional approach) are becoming increasingly mainstream.

But have project management and contract structures kept up with this trjaectory?

This article looks at the key differences between Agile and waterfall projects, the benefits and risks of Agile projects and how traditional software development contracts might need to adapt for Agile projects.

Agile versus traditional development

With a traditional waterfall approach, a development project is divided into a sequence of distinct phases: initial planning, definition of customer requirements, design of the solution to meet those customer requirements, development/build of the software code, testing and deployment of the finished product into the production environment, and a formal procedure for overall customer acceptance at the end of the project.

The waterfall approach assumes that each phase of the project can (and should) be completed before starting the next phase, and that the customer will not receive any working deliverables until the project is completed.

By contrast, Agile development projects feature repeated short development cycles (usually referred to as "sprints"), including planning, design, development, testing and deployment activities, each covering a small subset of the overall requirements, and meaning that useable software code can be delivered to the customer more regularly throughout the life of the project.

Differences between Agile and waterfall projects include:

The risks of Agile

The key advantage of the Agile approach is that the software design can remain flexible and adaptable over the life of the project, and reflect any changes to the customer's requirements as they evolve.

By contrast, a waterfall project can lead to a system being developed that conforms to the requirements that the customer had in mind at the outset, but which might become less relevant over time (particularly for a lengthy project).

Agile will not be appropriate for all development projects, but works particularly well where a customer is looking to rely on the supplier to help define how the final solution should work.

It also avoids a common pitfall of traditional development projects, where the supplier is getting stuck on a particular phase can stall the whole project. Agile development allows the supplier to move onto the next phase and deliver usable code to the customer at regular intervals.

That said, Agile projects can pose more commercial and legal risk to the customer than traditional waterfall projects if not managed properly.

This makes choosing the right supplier even more important, but also puts more of an onus on the customer to remain involved in the development process an engage collaboratively throughout the project.

Read on for practical tips on making your supplier partnership watertight in an agile environment... 

• The Product Backlog of requirements is not fixed or subject to a formal change control procedure as is common for waterfall projects. Instead the customer may reprioritise the list of requirements or add or  remove requirements at any time between sprints.
• Project management is shared by the customer and supplier through regular planning and review meetings before, during and after each sprint. In a traditional waterfall project, the supplier is usually tasked with the majority of project management activities and must deliver the project according to the agreed project plan. In Agile projects the customer will provide an estimate to the supplier of the overall project duration based on an estimated number of sprints, with each sprint being for a specified duration (often between 2 to 4 weeks), but the actual duration of the project is dependent upon how long it takes to complete all of the items on the Product Backlog. The consequence of this is that the customer needs to be comfortable with the risk of timetable slippage, and the supplier is generally not measured against fixed milestones as they would be for a waterfall project.
• Waterfall projects usually have a formal acceptance procedure at the end of the project, but in an Agile project, testing and acceptance against the shortlisted requirements is carried out during each sprint. Any outputs that fail to achieve acceptance during a sprint go back into the Product Backlog and must be redelivered during a later sprint.

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