Agile contracting in Government

Kay Chand and Aaron Singh examine the benefits and pitfalls of agile software contracting.

When it comes to the development of software, the traditional model for development is a process known as “waterfall”, whereby one phase needs to be completed before moving to the next phase. A waterfall approach is often considered as a linear and sequential style, where phases flow downward to the next. This approach requires the functional and non-functional requirements to be defined at the outset so that the build and testing phases can be carried out to ensure those requirements are met.

The charging mechanism for waterfall contracting tends to be fixed price for licence and support (and hosting where this is also required), and will sometimes have additional time-and-materials pricing in respect of consultancy services required for installation/implementation. Depending on the nature of the consultancy and the bargaining strengths of the parties, it is not unusual to see fixed-price mechanisms in respect of consultancy services being payable against achievement of milestones. There may also be consumption-based charging mechanisms included in respect of operational services to provide for a scalable solution. Agile contracting is an alternative method to a waterfall structure, using instead an incremental approach based on principles which focus more on individuals, interactions, results, collaboration and flexible responses to change. Essentially, agile contracting breaks down the process into small steps which are delivered in short timeframes (also known as “sprints”). Sprints could include design, development, testing and showcasing. The principles do not follow a linear start-and-stop process, but instead favour a constant cycle of small processes as required to improve output.

Each deliverable or iteration goes through a lifecycle, which can be anything up to around four weeks. The lifecycle includes designing, building and testing the deliverable or iteration to eventually 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 meetings are held where the parties report on:

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

This methodology is preferred where an organisation is aware that it needs a technological solution but does not know what that solution might look like in terms of functionality and/or performance. It may therefore decide to build up the solution on an incremental basis via storyboards and product backlogs.

This allows flexibility to work up the solution and tailor it to the requirements of the organisation piece by piece. However, a pure agile solution is usually charged on a time-and-materials basis, without certainty of tangible outputs.

Key benefits and pitfalls

By following an agile approach, a project with a number of sprints can benefit from faster software-development lifecycles, flexibility in adapting to change, and greater efficiency in communication between teams.

A common concern with agile working, arising from the fluidity in working processes, is the lack of certainty on charges and tangible outputs as mentioned. 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);
• fixed price per iteration or deliverable.

A clear distinction between agile and waterfall contracting is agile contracting’s emphasis on collaboration. Throughout the deliverable or iteration lifecycle, both parties will work together at each stage to achieve the objectives. 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.

Recommendations

Given that there is a lack of certainty on costing in agile-working models, Government bodies should proceed with caution to ensure budgetary constraints and objectives and requirements can be met. In our experience, once the risks of agile contracting have been explained, clients shy away from the model and quite often end up with a hybrid model which is, in our opinion, unsatisfactory from a contractual perspective. This is usually because legal advice is sought later in the process when the supplier has already convinced its customer that agile is the right way to go!

When negotiating a contract based on agile principles, Government bodies should consider the scope of work and ensure that it includes definitive measurables on how to determine progress in the project. Such points are often excluded or unclear within an agile model.

Agile contracting typically focuses on dynamic fast-paced delivery, creating a risk of substantial strain on the teams involved in delivering the product. As such, Government bodies must ensure that appropriate and skilled resources are available and utilised effectively for the particular project. Significant and high-level stakeholder input will also be required in order to make real-time decisions on the development of the project throughout its lifecycle, which is a significant commitment when compared to a traditional waterfall model.

If a Government body has a set budget and wants control over charges, then agile contracting may not be the right way to proceed. However, if there is some flexibility around budget and the overriding objective is to ensure that the solution fits the need, then agile contracting methodology may be a consideration.

Kay Chand is a partner and Aaron Singh is an Associate at Browne Jacobson.