In recent years, we have seen a growing number of our clients adopt agile methodologies (“Agile”) to develop software applications and more broadly as project management solutions. It is increasingly being viewed as the best way of achieving faster and better outcomes that meet actual business needs. In this article we will explore some of the challenges of contracting for Agile in IT projects.

So what is Agile? In essence, Agile is the repeated process of iteration and development that allows for the constant evolution of whatever it is you are building. Originally born out of software developers’ frustration with failed IT projects, Agile purists abhor Waterfall methodologies that are predicated on a linear sequential flow and siloed approach to delivery. They instead emphasise the importance of cross-functional teams working together effectively, embracing change during a project and adapting to it, and the prioritisation of working outputs over documentation. Indeed, Agile has a number of parallels with design thinking that places the customer at the “front and centre” of new design concepts: empathising with customer needs; applying those “needs” to ideation and prototyping phases; and implementing an iterative feedback loop to refine those concepts further.

Despite the grandiose promises of delivering faster and better outputs, Agile is often viewed with trepidation in large organisations and particularly for critical IT projects with longer development cycles. The lack of documentation and clearly defined outputs may not offer senior executives the comfort they need: “You are asking me to sink money into a 2-year project and I may have nothing to show for it?”  Delivery of little at a high price is often seen as the key risk of Agile projects.

As lawyers, we face important challenges in contracting for Agile (especially on the customer-side) that are often overlooked. How can we preserve the inherent flexibility of Agile and its benefits while also delivering the “certainty” that customers demand from their suppliers?  What happens if things go wrong or simply don’t proceed as envisaged?  We have set out below some of the key issues to consider from a customer standpoint:

1. Agile process – There is an array of agile methodologies (e.g. Scrum and Kanban being two of the most popular) and in any transaction the parties should agree on the approach they wish to use at the outset. There will likely be some debate as to the degree of granularity vis-à-vis the Agile process that should be included in the contract, however from a customer perspective it is important to be clear on the roles and responsibilities of the Agile team and the project cycles. For a Scrum project, this would include setting out: the identity of the “scrum master” and the “product owner” and their respective roles on the project; the duration of each sprint; how the testing process for each increment of software will work (including what is required to achieve the “definition of done”); and the process for returning incomplete items to the product backlog. This establishes clear expectations about how the project will be managed and it should enable progress to be tracked over time. Inviting senior stakeholders to demos at which they can review working software (rather than simply reams of documentation) may also help to “de-risk” the project from their perspective.
2. Commercial model – There are different commercial models that can be used on Agile projects and the emphasis is usually on encouraging positive behaviours: to reward the delivery of incremental outputs rather than to deduct payments for non-delivery. One approach is to adopt a fixed sprint-based charge that covers the supplier’s costs, with the bulk of their profit then being realised through “release charges” as operable pieces of software are developed or deployed. The sprint-based charge can also be variable, although difficulties then arise as to how you agree the level of fees given one party may unfairly cede control to the other. Other approaches include capped fee arrangements and the use of heavily weighted incentive models that allow for retention payments or bonuses to be paid to the supplier (e.g. by delivering under budget or within shorter timescales). Pure T&M is also an option, although this offers no budget certainty to customers and should be avoided in most circumstances.
3. Joint responsibility – In Agile projects, the customer plays a key role and the development teams are often made up of personnel from both parties. For example, in Scrum projects the “scrum master” may someone from the supplier’s personnel but the “product owner” would ordinarily be someone within the customer’s organisation who is responsible for deciding what the team will do, make or accomplish. This contrasts with a Waterfall approach, under which responsibility for developing a solution against a prescribed list of requirement (and any specification(s) that details how it works) is often placed squarely at the supplier’s door. The result is to blur responsibility for delivery and it can therefore be difficult to attribute blame in Agile projects as you would do for Waterfall, although we often see contracts in which customers try to do exactly that. In “pure” Agile contracts governed by English law, you should therefore consider alternative levers to the traditional rights and remedies that are commonly used in Waterfall as a means of holding the supplier’s “feet to the fire” throughout the project.
4. Scope creep – The inherent flexibility of Agile lends itself to changes in direction as projects get underway. However, suppliers rarely act out of love (although I stand to be proved wrong!) and a change in direction may well have cost implications for the customer. In Scrum projects, having a robust “product owner” (see paragraph 3 above) and a suitable governance regime should help to keep projects focussed and costs on track.
5. Walkaway scenarios – There may be instances where an Agile project simply isn’t going as anticipated without the demonstrable fault of either party. What do you do in that scenario? As a customer, simply having a right to terminate for convenience might leave you without sufficient IP rights or tangible documents to continue the project yourself or with another vendor. And from a supplier’s perspective, what pricing model have you negotiated and would an early termination leave you exposed financially? Restricting termination for convenience rights to formal checkpoints (with appropriate conditions attached) can help to alleviate those concerns.

“Wagile” – a middle ground?

To preserve the fluidity of Agile and yet also achieve some of the “certainty” afforded by Waterfall, customers should consider whether they can identify a set of core requirements (i.e. a “minimum viable product”) that the supplier is then required to deliver against. Even if the “MVP” only represents around 20/30% of the final solution, it will allow you to attach delivery timelines to the development of the MVP and to grant to the customer fault-based termination rights should the supplier fail to achieve them (e.g. a failure to achieve acceptance of the MVP by the “longstop date”), together with other consequences for late delivery e.g., a liquidated damages regime. You can also adopt a bespoke charging model for building the MVP (perhaps a fixed or capped fee component) with the incremental work being delivered through a “pure” (or purer!) form of Agile, once the base level of functionality is achieved.

Having said that, it may not always be possible to identify an MVP in this way and each IT development project will inevitably have its own idiosyncrasies. Therefore you may need to be creative in order to identify the appropriate contractual levers that will best protect your client’s interests.