The terms “agile”, “agile contracting” and “agile procurement” are used interchangeably by customers and suppliers to mean various things. Customers often refer to agile as collaboration between supplier and customer or working together in partnership. The terms and conditions for such transactions rarely reflect these working arrangements and nor, when pressed, do customers tend to want to reflect these working arrangements in the terms and conditions due to the inherent lack of certainty of the deliverables that will be produced through agile contracting, the pricing mechanisms associated with agile contracting and therefore increased risk when compared to traditional waterfall approaches.

A common misconception is that agile contracting will be a cheaper route to procurement and cheaper development of deliverables. This is not necessarily the case. Agile is a different approach to procurement underneath which sits a different contracting methodology.

Distinction between waterfall and agile

Traditional waterfall contracting requires the parties to determine, early on in the procurement lifecycle, the deliverables to be produced and the end to end delivery model. Therefore detailed service descriptions or service solutions need to be written at the outset. The waterfall contracting approach, which although can provide the necessary legal contractual certainty in a well written contract, fails to recognise that:

  • the technologies in today’s world means that services are capable of evolving very quickly;
  • customers may not have the resource and capability to define what they want at the outset;
  • suppliers may not have sufficient opportunity to conduct due diligence to determine whether their proposed solutions are fit for purpose;
  • services and deliverables will change throughout the procurement lifecycle.

Agile contracting methodology gets around some of the practical issues which the traditional waterfall methodology fails to. Agile contracting methodology is based on an iterative process executed via collaborative working arrangements whereby the deliverables are designed and developed on an iteration by iteration basis. Fundamentally, the parties are not contracting for an end to end solution defined at the outset but rather aspects of a solution which evolve and are built upon incrementally to achieve the overall business case and meet the objectives.

There is a lot of jargon in agile contracting such as “Scrums”, “Sprints” and “Timeboxing”. Use whatever terminology you may but essentially the process is this: each deliverable or iteration goes through a lifecycle which can be anything around four weeks. The lifecycle includes designing, building and testing the deliverable or iteration to produce a tangible product which has some value or benefit to the customer, such as a component of software.

Throughout the deliverable or iteration lifecycle , daily or regular meetings are held in which the parties report on:

  • what work has been completed since the last meeting;
  • what work is being planned to be completed before the next meeting;
  • any obstacles to completing the work.

A clear distinction between agile and waterfall is that agile has an emphasis on collaboration. Throughout the deliverable or iteration lifecycle, both parties will work together throughout each stage to achieve the objectives. The collaboration effort will be greater during the design phase where the parties work together to determine the functional and non-functional (such as look and feel) requirements of the deliverable or iteration. Agile contracting is therefore much more resource intensive on the part of the customer compared to what customers may be used to in traditional waterfall contracting.

Click here to view the image.

Notwithstanding the collaborative nature of agile contracting methodology, the methodology is driven through the pricing mechanisms which for true agile can only be on a time and materials basis. The more the parties move to fixed scope and fixed price contracting, the more the parties move away from agile contracting methodology. Variations to the time and materials pricing mechanisms can be adopted such as:

  • time and materials capped per iteration or deliverable;
  • time and materials capped per iteration or deliverable with adjustment. (The adjustment would apply where the time and materials charges accrued are less than the agreed cap. The parties may agree that the difference between the cap and the accrued charges are apportioned between the parties);
  • target cost pricing. (This is a gain/pain sharing mechanism where the parties agree to allocate an agreed adjustment amount if the actual costs exceed or are less than the agreed target costs. For example, if the target cost is exceeded, the charges are based on the target cost (as opposed to the actual costs) plus the agreed adjustment which will be a percentage of the excess amount. If the actual costs are less than the target costs the adjustment is subtracted from the target cost (the adjustment again being a percentage of the difference between the actual cost and target cost);
  • fixed price per iteration or deliverable.

Mitigating risk

Agile contracting methodology is perceived by lawyers acting for customers to be a riskier approach to contract than the traditional waterfall approach. This is for two main reasons:

  • outcomes are uncertain and undefined;
  • the time and materials pricing mechanism gives the customer little certainty of overall project costs;
  • there is no certainty that the overall objective will be met and the customer may be delivered part of a solution or no solution at all.

These risks can be mitigated in a number of ways, including:

  • providing a right for the customer to terminate on a per iteration basis, for example, where an iteration fails to meet the acceptance criteria or for convenience;
  • adopting one of the pricing mechanisms referred to above;
  • including traditional supplier incentives such as liquidated damages and balanced score cards;
  • clawback mechanisms for monies paid in advance for a deliverable or iteration which is not complete or has no commercial value;
  • through effective governance arrangements ensuring communications lines are clear and regular, providing for expedient escalation arrangements;
  • through effective management arrangements such as recording what has been agreed, controlling changes to agreed documentation; development and maintenance of status, issues and actions logs.

The correct balance needs to be struck in the contract against granting the customer appropriate rights and protections whilst not stifling collaboration and innovation. The more constraints and rigidity introduced into the contract, the more the parties move away from agile contracting methodology.