How to write supplier contracts for agile software development

Agile risks

Callum Sinclair, a partner at law firm DLA Piper, says the vast majority of contracts are still waterfall-based, but agile development is growing in use. This poses a number of risks to both sides, however.

“Heavily regulated organisations such as banks are getting into agile in a big way, pushed by their business and IT teams hungry for a flexible and agile way of working to deliver products much faster to market,” he says.

Internal legal and risk functions recognise that they must embrace agile contracting, but problems arise over the sharing of responsibilities; they must find ways of managing and mitigating risk rather than resisting it or trying to push it where it doesn’t belong.

Nicholas Mitchell, an associate at technology law firm White & Black, takes the developer’s point of view. He says developers believe that agile delivers a higher quality solution in a more efficient way: “For many, it is simply the way in which they are now used to working.”

Considerations for agile contracts

It should go without saying that IT leaders considering any project need to be clear about its aims and objectives. But with agile the need is greater and a view has to be taken on whether it is suitable or desirable for the project to be managed in an agile way. “Where a project is suitable or where agile may be a possibility, it is necessary to ensure there is sufficient flexibility in the procurement processes to support suppliers to get the best out of what agile has to offer,” says DLA Piper’s Sinclair.

White & Black’s Mitchell says parties drafting agile contracts need to be flexible enough to realise the benefits while accepting the reality that many software contracts end in failure, whether agile or otherwise. “While advocates of agile are optimistic about its ability to deliver based on mutual trust, lawyers tend to look at contracts as mechanisms for apportioning risk,” he says.

So by dint of the differences between agile and waterfall, project managers need differing briefs and forms of interaction with suppliers. The brief needs to reassure management and IT functions about agile, including the fact they will not see many of the traditional contractual protections they are accustomed to, and that these will be replaced by other forms of risk mitigation.

According to Sinclair, the projects that work well are generally those where customer and supplier both have experience of working in an agile way – and ideally with each other, so there is already a track record. 

“There will be more work to do where the relationship is new. In particular, education of the customer-side resource will be required through the development lifecycle because of the degree of day-to-day collaboration, which would not traditionally be the case with a waterfall development project,” he says.

Subtle differences between agile and waterfall

While a contract is the heart of any project, and there are similar points to be covered off in both agile and waterfall arrangements, there are subtle differences in approach required with agile development.

As Mitchell puts it, it is not simply a case of describing what you want as a customer and leaving the supplier to it, only interacting when problems arise. Consider, for example, the Scrum methodology where the product owner is key, says Mitchell: “Product owners must be continuously and intimately involved with everything the development team should be delivering, as well as communicating with stakeholders on the customer side.”

Equally, with extreme programming projects or other situations where customer and supplier resources are developing in close proximity, there will be a blurring of lines which might need addressing in intellectual property rights and liability provisions. Sinclair also points to the issue of termination provisions as these may need to allow customer a “no fault” termination right at the end of each iteration/sprint.

There is a need with agile contracts to draft the extent of customer-side delegated authority: what happens if there is disagreement over any given user story; the process when new user stories need to be introduced; and what is the definition of “done”. Sinclair sees the need for a common understanding of the project and a reference point for managing disagreements.

While the process, roles and behaviours should be documented, the key issues for customers are often a lack of visibility of the price, the solution and the time for delivery. Contracts need to stipulate this.

The financial terms of agile contracts

The financial terms of an agile contract can be a source of tension. Both Sinclair and Mitchell agree there is an argument that “pure agile” can only be done on a “time and materials” basis – paying for third-party resources based on the number of hours or days they work, rather than for a price fixed up-front.

Agile purists would argue that working software matters more than comprehensive documentation and some projects may never be finished

Sinclair says that, generally, customers will ask for some degree of additional protection through a hybrid process, whether through a priced “minimum viable product” or an agreed process to arrive at a fixed price per sprint once the sprint plan has been put together. Mitchell notes that some Scandinavian models of agile contracts allow for a fixed price, or at least an estimated cost, while others have tied greater rewards to speedy delivery or more valuable functionality.

Fixed or capped prices are difficult to achieve in agile projects without impinging on some of the advantages of flexibility that proper agile projects allow. One approach is to share the risk and rewards so that projects blend time and materials with success-based delivery fees, but again, this requires good project governance to keep both sides happy.

In reality, though, there are a number of different pricing models that can be adopted, and it will come down to negotiating power and willingness to share risk.

Defining scope, time and completion

Bearing in mind that agile projects involve, to an extent, a moving target, then time-limited delivery dates can be problematic and may constrain matters. “Agile purists would argue that working software matters more than comprehensive documentation, and some projects may never be finished, yet each stage may be completed,” says Sinclair.

Many agile project management tools, for example Rally, have the ability to attach success criteria to individual user stories as part of the product backlog, and these can move with those stories between sprints if necessary. Sinclair says achievement of these criteria may provide the best definition of “done”, though there are other ways to do define this.

Of course, the wonder of agile contracts is the ability to dump functionality that the customer wanted, to get to a lean solution that fits actual business needs. This is something that Mitchell says must be permitted: “Customers often have their own business needs about time for delivery and suppliers have to be able to meet those – they too must be documented.”

Handling disputes

One benefit to agile is the lower likelihood of needing lawyers because of the “fail faster” principle where smaller amounts of work may be discarded if it appears to be unnecessary or not working. Sinclair suggests that disputes are less likely – or problems will be visible much earlier – because of the way user stories are developed. Agile allows for the collaborative resolution of disputes at an earlier stage to keep the project on track.

“Change is an inherent part of the agile process, and the relevant individuals, such as the product owner, need to have the authority to make necessary compromises quickly to deliver,” says Mitchell.

That said, contracts should contain a dispute resolution clause and a governing law and jurisdiction clause.

Terminating a project

The need to terminate a project is highly subjective and all the usual termination grounds apply, such as material breach, change of control or insolvency. But Sinclair says that with agile, there’s also the possible addition of a “no-fault” termination right for the customer at the end of each sprint, without termination fee or other sanction beyond payment for work properly completed, to reflect the agile approach of a working product at the end of each sprint.

But agile contracts may also expressly recognise termination by agreement of the parties as a natural consequence of the “fail faster” principle. This would apply where parties recognise at an early stage that they cannot achieve the aims they intended.

It’s worth noting that in practice with agile it can be more difficult for a customer to terminate for contractual breach as a result of unexpected delay, unforeseen cost over-runs or for the delivery of a product which ostensibly works but which fails to fit initial expectations.

Lessons to be learned

Most of the agile projects that fail do so because there is a misunderstanding of agile – usually on the customer side – and what that means for the working culture, project governance and the extent and involvement of customer resources. But even if that is understood, there can be a failure to communicate or obtain acceptance, and the consequences of that, from senior management. That, in turn, often results in a paring back of agile through fixing budgets, timescales and minimum deliverables to try to obtain traditional contractual certainty at the expense of genuine flexibility, such that the project is hamstrung from the outset.

Sinclair says all of these points result in lawyers, whether in-house or external, putting in place contracts that lean far more towards waterfall developments. “Sadly, when a project hits trouble, agile is blamed – and that gives agile a bad name. For some reason, agile failures are always trumpeted far louder than success case studies – very often the reasons for failure are down to poor project governance and nothing to do with agile,” he says.

Mitchell sees the biggest problems arising where a project has not been written as an agile contract but the parties decide to switch to agile methodology because traditional methods failed – as happened in the BBC’s failed digital media project in 2013. 

“In practice, this often means abandoning pre-defined requirements and change control in a last-ditch attempt to deliver. This makes it extremely difficult to preserve the customer’s rights to a claim for breach if the project does not succeed,” he says.

Experience seems to dictate that agile works best on limited projects delivered by small, co-located teams. Opinion is divided as to whether it is effective for major government projects, and certainly there have been some high-profile problems. But some would argue that this is because the projects, culture and processes involved were not truly agile.