Agile Software Development

"Agile" is an umbrella term for a group of software development methodologies. Common characteristics of these methodologies are that:

This Quick Overview (i) gives a brief explanation of Agile, (ii) contrasts one particular Agile methodology - "Scrums" - with traditional "waterfall" development, and (iii) highlights some issues for lawyers drafting Agile contracts. These techniques and organizational methods can be used around the world.

The "Agile Manifesto"

The Manifesto for Agile Software Development, set out below, was formulated in 2001 by a group of software developers:

A set of 12 principles underpin and expand on the manifesto.

Examples of Agile methodologies

Some examples of software development methodologies that fall under the "Agile" umbrella include:

 

Although these methodologies share common Agile characteristics, there are differences. If advising on or drafting a contract for Agile development, it is important to understand the exact methodology the supplier will be using so that the contract can be tailored accordingly.

Traditional "waterfall" development v. Agile scrums?

The aims of Agile are best illustrated by comparing an Agile methodology with a traditional "waterfall" software development project.

In the "waterfall" method, the scope of the software to be delivered is fully articulated at the outset. The parties agree the customer's business requirements and a technical specification, and the contract usually specifies that the supplier must deliver software that meets the agreed business requirements and the specification by a certain date (or in phases by certain dates).

In general, the usefulness of the software is only realised at the end of the project once all elements have been delivered. Therefore, although user and supplier testing may happen in phases, and indeed formal contractual "User Acceptance Tests" may happen in phases, it is only at the end of the project that the customer is usually willing to "Accept" all of the software delivered under the contract. The customer usually negotiates so that it can reject all or part of the software if any part doesn't meet these final tests. Interim testing can be useful in its own right but typically simply marks milestones or checkpoints along the way. Any changes to the project are dealt with through a formal change control procedure, giving the supplier the opportunity to increase charges or extend the timetable to deliver the required change.

In Agile scrums, at the start of the contract there is no detailed set of requirements or specification. Instead, a set of high level business objectives is identified at the outset. During the early stages of the project, the customer and supplier develop a "product backlog" describing the functionality to be developed to realise these objectives. The product backlog continues to evolve until the development process comes to an end. The product backlog may include technical details as well as "user stories" (descriptions of what the software should do or achieve from a user perspective).

The product backlog is prioritised so that the most important functionality is delivered first. The parties focus on fleshing out and developing functionality at the top of the list as this will be built soonest. Functionality that is lower priority remains in outline only until it nears the top of the list, at which point the parties develop this into detailed functional specifications.

Functionality from the product backlog is developed during fixed iterative cycles, usually lasting between 2 and 4 weeks. Each iteration or "sprint" is essentially a time-boxed period of development. During each sprint, the functionality is built, tested and deployed. Software is often evaluated daily and incrementally as further code is added. Once a piece of functionality is built and meets an agreed "Definition of Done", it is removed from the product backlog.

The time allowed for each sprint is never extended. Any functionality not completed at the end of a sprint is identified and added back into the product backlog for development in a future sprint. Allocating functionality to the product backlog is not a "delay" or breach of contract on the supplier's part and the customer therefore usually has no right to claim damages for delay or non-delivery. At the end of each sprint, lessons are learned and these may inform and improve delivery under later iterations.

At any stage during the project (except for functionality which is earmarked for development under the current sprint), functionality can be added to or removed from the product backlog or re-prioritised. This is carried out through an informal change process and while it is important to log these changes, they happen day-to-day and are not processed through the type of formal "change control process" that you would see in a traditional waterfall contract.

It is important to understand that this process requires a high level of collaboration between the customer and supplier. The customer has high visibility and plays an important role in what is being worked on, how it is progressing and what is being prioritised or put on the backlog.

This iterative process is repeated until the whole product backlog is developed or it is decided that the development is stopped, either because the development has not been successful, an alternative approach is to be adopted or because the business objectives have been sufficiently met.

What are the benefits of Agile?

Agile approaches:

Some contractual issues

For the customer, Agile is a significant cultural step-change from traditional waterfall developments. The success of Agile does not rest solely on the supplier's shoulders. The customer is an integral part of the development team and works side-by-side with the supplier (sometimes physically, sometimes virtually) to set requirements and priorities and to regularly assess and provide feedback on software as it is delivered. Success therefore also depends on the customer being "Agile-ready" with a team of personnel trained and experienced in Agile implementation. The fact that the customer plays an important role in the development process necessarily means that the contract will look very different to a waterfall contract, particularly when it comes to the allocation of risk between the customer and supplier for delivery of the software.

Continuous and effective communication between the customer and the supplier is essential. The fast-paced development environment demands quick, project-level decisions, and this means that members of the development team on the ground need to be empowered to take those decisions. This should be reflected in the governance provisions in the contract.

As well as fault-based termination rights, customers usually want to be able to terminate once their business objectives have been met, without incurring any penalty. After all, the objective of Agile is to incrementally deliver working software and to continue to hone requirements until the software delivers sufficient value for the customer's purposes. In a scrum scenario, this usually translates into the customer having the right to terminate at the end of a sprint. Early termination can be a challenge for suppliers, especially if the supplier hasn't yet had a chance to recover its upfront costs. As a middle ground, the customer might agree not to terminate without cause before a certain date, or might agree to pay a termination payment calculated on a sliding scale and based on an initial estimate of work.

Pricing is one area where inherent tensions between Agile and risk allocation often come to the fore.

T&M pricing is the most straightforward model when it comes to Agile and is preferred by suppliers; but, without additional protections, a pure T&M model can leave the customer exposed to escalating costs. Hybrid pricing models that combine elements of T&M with gain/pain share (see below) can help to give the customer some comfort.

Fixed price models give the customer price certainty but do not generally sit comfortably with iterative developments. Suppliers are understandably wary of fixing a price against high level requirements and a fluid scope of work. One option is to fix the price per sprint based on an estimate of the work required. The requirements for the sprint would have to be sufficiently detailed to allow the parties to determine the amount of work required. Metrics such as "function points" (agreed units of measure of effort and/or richness of functionality) can be helpful in allowing the parties to estimate the amount of effort and/or functionality required in a sprint and can therefore inform pricing.

Hybrid models that combine T&M pricing with incentives to encourage efficiency can help to give customers more comfort around costs. For example, the customer and supplier could agree a target price for a sprint. The supplier's fees would then be calculated on a T&M basis. If the target price for the sprint is exceeded, then the customer and supplier share the overrun. If the T&M price comes in below the target, then the customer and supplier share the savings by allowing a bonus payment to the supplier calculated as a proportion of the under-run.

Conclusion

Agile methodologies demand a different type of contract. The sorts of provisions and protections that lawyers might expect to see in a waterfall contract (fixed price for fixed scope, close management of changes to the customer requirements and/or technical specification, the supplier assuming most if not all the risk of delivery, liquidated damages for delays etc.) are displaced, and instead there is a greater focus on governance, open communication, collaboration and process.

Additional resources

https://kenschwaber.wordpress.com/ (Ken Schwaber is one of the co-creators of the Agile software manifesto.)