How to Build an Agile Contract

How to Build an Agile Contract by ITGP author of the month, Jamie Lynn Cooke

Establishing a contract that genuinely supports Agile methods can be a significant challenge for your organisation.  By its very nature, a contract that specifies detailed upfront deliverables contravenes the principles of flexibility and adaptation that are at the heart of Agile. However, the actual problem is not the detail in a contract – it is the unspoken reason why the detail is there in the first place.

Although the detail in a contract is often mandated by compliance requirements, organisational standards and legal imperatives, underpinning this detail is a lack of trust in the relationship between the vendor and the client. By putting extensive detail into a software development agreement, the client is seeking protection from the risk of insufficient outcomes (or non-delivery of outcomes), budget overruns and missed deadlines. The more that this risk is perceived by the client, the more the contract will endeavour to mitigate the risk through an abundance of clauses to account for every possible contingency.

Agile takes a very different approach to working arrangements with clients. Instead of focusing on faults and liabilities, Agile methods focus on collaboration, transparency and trust. The relationship between the client and the vendor is based on shared goals, shared knowledge, shared risks and shared benefits.

Here are guidelines for establishing a mutually agreeable contract that supports Agile methods:

Define deliverables as business objectives that are measurable instead of detailed requirements. For example, “the solution will increase staff output by 30% within six months of its release.”  If a contract is predefined with detailed functional specifications, the project team is generally handcuffed to the outcome from the beginning with little room to adjust the work as it evolves.

Detail the process, not the solution. Instead of providing extensive upfront detail on the solution that is the work product of the contract, focus on describing the process that will be used to ensure that the work product achieves the client’s objectives. The contract should explicitly identify that the vendor and client will jointly follow the Agile practices of working collaboratively, focusing on the highest business-value capabilities as defined by the customer, and adjusting ongoing work based on the customer’s regular review of delivered outputs.

Structure pricing by iteration: Most standard IT contracts structure payment milestones around the completion of software development life cycle (SDLC) phases or around the acceptance of pre-defined deliverables. Agile contracts should structure payment milestones around the completion of work per iteration. The total value of the contract can be subdivided into an agreed number of iterations, with payment tied to the completion of a specified number iterations (i.e. one four-week iteration for monthly payments, three four-week iterations for quarterly payments).

Build in flexibility where possible: Although contracts generally require enough structure to be enforceable agreements, there should be sufficient flexibility built into the contract terms to allow for agreed variations on deliverables, costs, delivery dates and status reporting mechanisms so that the agreed Agile method is not unduly constrained by predefined contract terms that contravene the process.

It is important to note that having an Agile contract structure does not negate the need for organisations to apply due diligence in their agreements by including standard contract terms and conditions.  Termination clauses, payment terms, confidentiality and intellectual property clauses are all necessary to protect the interest of the involved parties. The primary difference between a traditional contract and an Agile one is that the Agile contract stipulates a process for achieving successful outcomes, whereas the traditional contract handcuffs the parties to a level of predetermined detail that virtually assures that the eventual outcomes will be inadequate or obsolete.

The Power of the Agile Business Analyst, second edition – 30 surprising ways a business analyst can add value to your Agile development team is available to order from ITGP. Get 15% off when you order in June 2018 – enter discount code JULY15 at the checkout.