Agile development: overcoming the legal barriers It is possible to contract for Agile, but it requires getting rid of legacy templates and considering issues like risk sharing and governance

Agile is not new – Agile has been used for the development of software long before the Agile manifesto was created over 14 years ago.  Major Software and IT Services (SITS) companies, financial services business and government departments are all interested in using Agile for their major development programmes.

The technological revolution is constantly evolving and the pace of change is increasing with each advance.  Agile software development and project management methodologies reflect the way developers increasingly prefer to operate; typically they reflect speed and flexibility.  Looking at the number of job opportunities posted in forums like LinkedIn, analysts and project managers with Agile skills are in high demand.

Despite this, Agile is still seen as the next “new thing” waiting to happen. Why is that? What’s holding it back?

Lack of commercial models

A major barrier is the lack of commercial models for the supply of services using Agile methodologies: commercial models have not kept up with the pace of change in the technology marketplace.  Agile represents a cultural change; it’s inherently more collaborative in its approach and there’s an implicit acceptance that some iterations will fail.  This is anathema to lawyers who want to see certainty – certainty of cost; outcome; time; responsibility; risk transfer etc.

Traditional contractual models were developed from engineering and construction templates, using sequential phases that are normally described using the analogy of a waterfall.  Agile’s iterative approach, lack of a specification and mantras of “fail fast, fail often” does not sit comfortably with these legacy models.  A different approach is required that matches the flexibility of the new world models.

The benefits of Agile are simply understood, but what is clearly harder to achieve is the creation of a commercial model that properly reflects the principles of Agile.  Consequently, projects that set out to adopt the principles, like the Universal Credit programme, run the risk of failing to achieve their aims when they are forced to use models designed for a different approach.  Forcing Agile into a “waterfall” contract, dubbed “Agifall” by some commentators, is doomed to fail, providing fuel to detractors who focus on the lack of defined specifications and financial control as justification to relegate the methodology to low value or low risk projects.

Cultural change

Agile requires cultural change.  This is as true from the legal perspective as it is for development and project management.  Unfortunately, this is where the conservatism and risk aversion of lawyers becomes a problem; it is the desire for a predictable outcome, or at least the ability to provide remedies for failure, that acts as a barrier to the development of appropriate commercial models.

It is not helped that judicial precedent reinforces this conservatism. For example, a renowned case (St Albans Council v ICL [1996]) reinforced the need to develop and agree a clear specification; the supplier is liable for delivering a product that satisfies the specification regardless of whether the solution actually meets the customer’s needs.  Agile only seeks to establish a vision of the product and gives the customer the flexibility to identify when its needs have been satisfied.

Cost is also a barrier to flexibility; customers want cost certainty, and commercial models reinforce this when they require fixed or capped cost models.  This might work if customers could fully articulate what they want from the outset and developers could properly estimate the effort required to deliver a solution.  Something that is seldom possible even in the simplest projects.

Agile contracts need strong governance and risk-sharing

So is it possible to contract for Agile?  Yes, but it does mean starting with a different approach where the use of legacy templates is unlikely to be helpful. With this in mind, a common mistake that is made is the desire to describe the process.  In a mature market there is no need for this - both customers and suppliers will already understand it.  Mature contracts concentrate on identification of the rights and obligations of the parties.  Therefore, drafting needs to start from first principles and avoid trying to force Agile principles into a legacy waterfall agreement.  The result is that, like the inherent flexibility of Agile, the commercial models can be equally flexible.

Agile is a naturally collaborative approach that requires the parties to have a greater degree of trust in the process and each other.  Risk can therefore be shared recognising the symbiotic nature of the relationship.  It also encourages the use of more flexible approaches to the selection of commercial models, frequently allowing for the use of a variety of pricing tools to deal with fixed and variable costs equitably.

Underpinning this newfound flexibility is the need for strong governance.  Often an area for increased tension between parties, good governance in Agile can actually empower the parties to properly follow program management methodologies as they were intended to be used.

Article first published in Computer World UK, 26 January 2015