Improving Agile Contracts

With many years of experience of working with Agile, Simon Worthy gives an IT Consultant’s view of the ways in which lawyers need to improve their understanding of the workings of Agile

The purpose of this article is to add some practical experience of Agile Contracts, further explain Agile and provide a useful pointer for further reading to help produce better Agile Contracts.

By nature, Waterfall and Agile methodologies are very different. The author of the Contract needs to understand the Agile delivery method in order to build in suitable milestones and progress measures.

Software delivery failures

Projects are the means by which policy and strategy is implemented. Making a success of projects involving information systems is especially challenging. Decades of IS project management have failed to guarantee project outcomes, and new methods have not yet had an impact on complex and large projects.

The research clearly demonstrates that the larger the project the more likely it is to fail, to run over budget, or to deliver less than was required. The research also shows that the performance of large and complex projects has not improved since records were first captured in the 1960s.

Project Size






Over $100m





$10m to $100m





$6m to $10m





$3m to $6m





$1m to $3m





Under $1m




‘Situational Incompetence: an investigation into the causes of failure of a large-scale IT Project’. Darryl Carlton PhD


The Fundamental Difference between Waterfall and Agile

The traditional definition of ‘on time and within budget’ as a measure of success of an IT project is very misleading. A project can be on time and within budget but not provide the customer or end-user with what they set out to develop. A more accurate measure would be ‘does the development meet my perceived need?’. The perceived need often changes when the end-user is given some sight of the deliverable. In a Waterfall project the first sight of the deliverable is often at the end of the project in the User Acceptance Testing. In Agile projects the viewing of the deliverable is provided throughout the life-cycle of the project.  A Product Owner, embedded in the Scrum, can and will defer to the Business Sponsor and Users and will constantly refine their requirements. Another technique to refine requirements in-flight used in Agile Scrums is to conduct ‘Show and Tells’ when the development is at a stage to be confidently shown to Subject Matter Experts (SME) or users.

At this stage the requirements can be refined. If the refinement is considered to be too large to fit into the ‘committed’ Sprint then the change can be put back into the BackLog for a subsequent Sprint. In a traditional Waterfall project the customer and end-users do not see the application until the end of the project. By then the requirement will have changed, and the end-result will not meet the business needs.

By time-boxing stories into Sprints, and knowing the backlog at all stages, prioritising the stories within Sprints and having an embedded Product Owner and end-user inclusion with the Sprints, the risk of producing a delivery that does not meet the user requirements is much lower.

The project may run out of budget with a sprint to go, but having prioritised and delivered the critical stories early, the remaining stories are of lower risk and a decision can be made from a knowledgeable backdrop as to how to move forward. Also, at this stage some meaningful deliverable will have been developed and can be used, meaning unlike Waterfall a large portion of the project has been delivered and not all of it is wasted.

Cone of Uncertainty

cone of uncertainty graphic

The Cone of Uncertainty

The Cone of Uncertainty shows that at the start of the project the scope of the project is woolly and only over the project lifetime does scope become understood. With a traditional waterfall approach the requirements can change widely from the projects inception. Waterfall dictates that the requirements are not changed during the project but a Change Request (CR) is raised and developed after the project is completed. A typical waterfall project will have a number of CRs raised through its life-cycle.

Agile is more flexible. Very few Agile projects are pure Agile. Pure Agile requires Continuous Integration. Continuous Integration means that small, often discrete chunks of the project deliverables are deployed into Production. In reality, it is true that the software is deployed to Production in small deliverables, but the software is not turned on. It may be that it is deployed but waiting for further deliverables before the software is turned on.

For Continuous Integration to succeed a regression testing step is needed prior to deployment. Before the software is integrated into the Production site it should run through a growing and evolving regression pack. Automation in this area is becoming increasingly fundamental to providing an Agile delivery and the level and nature of the automation being used needs to be specified in the Contract. Also an impact statement needs to be undertaken to determine the risk if automation isn’t used or doesn’t work. Automation is a dependency in the Agile Project.

The regression pack reduces the risk of the Production suite breaking with the introduction of the new integrated software.

‘Continuous’ in the context of Continuous Integration can mean a number of things depending on the flavour of Agile that has been adopted by the development teams. This should be defined in the Contract. ‘Continuous’ can refer to a daily integration of the developed and tested product into Production, or it can mean that the software delivery can be deployed at the end of every Sprint. There are different variants depending on the Agile used.

Risk-based Sprints

The contract for an Agile project must be far different from a Waterfall contract. A book by Susan Atkinson and Gabrielle Benefield entitled Flexible Contracts describes the creation of Agile contracts. Susan gave a presentation to SCL members in 2010 on Agile Contracts, has written or co-written various articles for SCL and the new book provides a great framework for writing Agile Contracts.

With Agile projects, the risk of failure is less than with Waterfall projects. Failure in this context can be defined as not meeting the customers need. Even the risk of ‘on time and within budget’ is reduced with Risk Based Sprints.

A traditional scenario in a Waterfall project, is where the project is 66% through but has run out of days and money to finish. Testing is told ‘you need to perform your testing in half the time’. The response of the test manager should be ‘Ok, which half of the system do you want tested and which half is not to be tested’. This creates a huge risk and leads to project failures on a catastrophic scale.

Agile Team Members

The Product Owner is an essential difference between Waterfall and Agile methodologies. The Product Owner is the key representative of the Customer. As a Subject Matter Expert they are responsible for communicating the Customer’s vision of, and requirements for, the project to the Development Team.

The Product Owner will also take primary responsibility for the Product Backlog, including its initial development and its ongoing revision during the project.

They will participate in meetings with the Development Team during each Sprint, including meetings called to assess developed items. In a well-run Agile project, with a Product Owner embedded in the scrum, the risk of impacting the quality of the testing, reducing the coverage tested and working long, extra hours resulting in more human error will be avoided.

A Scrum relies upon three key roles: A Scrum Master, Development Team and a Product Owner. At the start of each Sprint, these key team members determine what will be developed, tested and committed to in the Sprint. The team will decide and commit to what can be achieved but selection of the priority stories is predominately decided by the Product Owner. This process ensures that the stories selected are the items that are required.

Typically, a project will be made up of a series of Sprints. Often, though it is not mandatory, with a production deployment at the end of each sprint (after a regression test). This will depend on the style of Agile which is adopted.

The Contract Model

evolutionary contract model

The Evolutionary Contract Model

An Agile project, run properly, will reduce but not remove the risk of the software delivery going wrong. Adoption of the techniques above, such as risk-based prioritisation in Sprints, embedded Product Owners and on-going business inclusion within the software delivery lifecycle, will reduce risk.

This does not negate the need for a contract being drawn up. Using a flexible contract or an Evolutionary Contract Model will best fit the Agile approach, as compared to the traditional Contract Model.

As mentioned above, three fundamental roles for a Scrum are: A Scrum Master, Development Team and a Product Owner. A key part of the Agile Contract is to apply some rigour around roles.

Product Owner

Key issues to be addressed in the contract

  • The Product Owner is the representative of the Customer, nominated and appointed by the Customer and named in the Contract.
  • Assurance may be sought by the Supplier from the Customer that the nominated Product Owner is suitably experienced in Scrum development projects.
  • The contract should set out the key responsibilities of the Product Owner, including:

  1. the initial development and prioritisation of the Product Backlog;
  2. the ongoing revision and re-prioritisation of the Product Backlog as the project develops; and
  3. participation, on behalf of the Customer, in the relevant Scrum planning and review meetings

  • The importance of the Product Owner role in the overall project, should be reflected in the Contract and the contract should require the Customer to use reasonable endeavours to ensure that the Product Owner:

  1. dedicates a reasonable amount of their time and efforts to the above activities;
  2. responds to questions from the Development Team as soon as possible; and
  3. is not removed from the project without good cause.

The Development Team

Key issues to be addressed in the contract

  • The contract should identify the proposed Development Team
  • Each member of the Development Team should be appropriately skilled and experienced to carry out the development project.
  • The Customer is entitled to confirm whether or not the proposed Development Team is acceptable. If the proposed team is not agreed by the Customer:

  1. the parties should use reasonable endeavours to agree the composition of the Development Team; and
  2. if the parties are unable to agree the Development Team within a specified period, then either party should be able to terminate the contract without liability.

  • The Supplier should ensure that each member of the Development Team:

  1. is dedicated to the project during the development period (unless otherwise agreed); and
  2. is not re-assigned from the project without the prior written consent of the Customer.

The Scrum Master

If a Scrum Master is to be used in the project then the key role of the Scrum Master in the contract should include:

  • The contract should identify the proposed ScrumMaster and set out the level of skill, experience and qualifications required of any ScrumMaster.
  • The key responsibilities of the ScrumMaster should be set out in the contract.
  • The contract should require that the ScrumMaster:

  1. is dedicated to the project during the development period (unless otherwise agreed); and
  2. is not re-assigned from the project without the prior written consent of the Customer.


Projects run in any variation of Agile require a different form of Contract. The Traditional Contract will not fit. Transparency of the BackLog, Velocity and Issues Register will provide early signs of any issues.

As with all Contracts the work is needed up-front. The contract should clearly define the Scrum Structure, such as the Sprint Duration, the Deployment/Integration requirements, the Agile Team structure, with particular concentration on the Product Owner. Milestones, deliverables and Stage Payment points.

Simon Worthy LLM MBA is an IT Consultant with extensive knowledge in Agile working for IT Probity and a member of the SCL

Published: 2018-08-24T12:30:00


      Please wait...