Contracting in an agile world, part 2

For part 1 of this post, click here

The emergence of agile development

Agile development emerged during the mid 1990’s and early 2000’s as a grass-roots reaction to the problems of traditional development experienced in many projects. There is no official definition but rather a set of principles, the most authoritative text being the Agile Manifesto.

Principles contained in the Agile Manifesto include:

  • Customer satisfaction through early, continuous delivery of working software;
  • Welcoming changing requirements, even late in development;
  • Clients and developers working together throughout a project;
  • Regarding working software as the primary measure of progress.

This requires a significant departure from the structured processes of traditional development. It allows developers and clients to adapt a project as it progresses. It allows software to be delivered and used continuously and problems corrected early and often. It encourages large projects to be broken into smaller projects, with functionality being added incrementally. It allows developers and clients to provide ongoing feedback and refinement as the system is developed. This dynamic can be invaluable in today’s business environment where businesses must be ready to adapt their business processes to meet market conditions and new technologies.

On the technical front, agile development encourages flexible system design through the use of software patterns, standards and best practices. Project management models have been created specifically for agile development and a range of sub-methodologies under the “agile” umbrella have emerged.

Agile development is not intended to replace traditional development but is an alternative methodology. Traditional development is still used on many projects and has many benefits. However, agile development has become increasingly popular, and by some estimates (see here and here) is now the predominant development methodology in use today.  It appears to be successful.  The Standish Group’s 2006 Chaos Report attributed the decreasing failure rate to 19% in part to agile development.  Other evidence supports this conclusion.

Contrasting traditional versus agile development

The following table contrasts key elements of traditional versus agile development.

Traditional development Agile development
Locked-in requirements at the start. Expect and welcome in-project requirement changes.
Formalised change process. Less formal change process.
Strict timetables. Smaller deliverables with flexible, incremental timetables and continuous delivery.
Segregation of responsibilities. Collaboration.
Sign-off & handover. Working software delivered frequently.

These elements are discussed below.

Continuous delivery

It is common for software development contracts to define deliverables to be handed over at the end of a project. For example, the deliverables may be a functioning system meeting the contract specifications together with completed documentation and other supporting artefacts.

In contrast, agile development promotes continuous delivery throughout a project where incrementally updated versions of a system are delivered as they are available, with the objective being to enable the client to begin using the software as soon as possible, even if only for a subset of the final intended functionality. In this way, flaws in system design can be detected and remedied earlier than would be otherwise possible and feedback can be acted upon.

At this point, it is worth asking “why would anyone want to use an incomplete system?” The answer is, by breaking large projects into smaller projects, it can be possible for even a very complex system to be delivered incrementally. How each interim delivery should be used depends on the project, with options ranging from production use to basic testing, and go-live risk management provisions should always be in place. Ultimately the extent and manner in which continuous delivery is viable and sensible for a given project is a commercial decision.

In-project requirement changes

Every software development project needs some up-front requirements analysis. The extent and formality of the initial analysis phase will vary project by project. Traditional development relies on heavy up-front requirements analysis (Big Design Up Front) which is typically incorporated into a contractually binding specification. It is not intended that continuous or major changes be made to the specification during the project.

In contrast, agile development expects, and even welcomes, changing requirements during a project, even at a late stage. This is essential to agile development. It allows the project to develop and evolve incrementally and respond to changes in business processes that it seeks to implement.

This may appear contractually problematic, even dangerous, and indeed it would be if it were allowed to be uncontrolled. A sensible change process must always be defined, together with parameters to control project scope including technical direction, timelines and cost. There is no reason why agile development projects cannot utilise common contractual elements for controlling scope while still allowing the desired flexibility for regular requirement changes.

Collaboration

Collaboration in the sense of agile development means the process of ongoing, regular, formal and informal communication and co-operation between the client and the developer, even to the extent of working together on a daily basis throughout a project. This contrasts with the customer-vendor model of traditional development, where the developer works on a project off the specifications largely in isolation from the client and “hands over” the finished product at the end of the project.

While traditional development often utilises control groups, steering committees, scheduled reviews and the like as effective forms of client-developer collaboration, agile development seeks to go much further. Agile development advocates having representatives of the client and the developer working together constantly throughout the project. This raises potentially thorny legal issues such as representations, authorisations and estoppel. These are issues which must be considered both practically and legally in all software development projects and there is no reason why an agile development project cannot utilise the protections against these risks commonly found in traditional development contracts.

Again, the manner and extent of collaboration is a commercial decision for each project and the practicalities of this arrangement should be clearly defined at the start of a project.

Finally, in conclusion…

To lawyers, agile development may appear an unattractive or even counter-intuitive option when compared to a highly structured traditional development project. After all, how can a contract accommodate informal requirement changes, continuous delivery, close collaboration and other “agile” processes while still providing the clarity, safeguards and controls required in commercial dealings?

It must be remembered that it is the problematic rigidity of traditional development that agile development specifically seeks to avoid. This is not for the purpose of reducing liability of any party, but to reduce the risk of project failure. A heavyweight, rigid contract may provide greater advantages to a party in the event of litigation, but for some projects may actually increase the likelihood of litigation.

Whether or not to use agile development on any given project is ultimately a commercial decision. It is one that incurs a risk versus return trade-off like anything else and clients must be in a position to make an informed decision.

The key issue where agile development is desired is that the contract supports the necessary agile processes. Contracts used in agile development projects must be drafted to ensure that the agile processes are not curtailed by a contractual regime better suited to traditional development. This does not mean that contracts should be any less clear and precise than they otherwise might be, nor does it require the diminution of standard commercial safeguards and time and cost controls. But it does place a greater onus on the drafters of contracts to ensure that clients and developers can reap the benefits of agile development under a contract supportive of that methodology.