CHAPTER 16: ESTABLISHING AGILE CONTRACTS
If you manage an IT department that develops software for external clients, you will find that establishing a contract that genuinely supports Agile approaches can be a significant challenge for your organization. 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 approaches63. 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, organizational 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 endeavor 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 approaches 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.
This section provides guidelines for establishing a mutually agreeable contract that supports Agile approaches – and, equally, for adapting existing contracts to allow Agile approaches to be used by your development staff.
If you are in a position to control the content of your software development agreement, then there are four key elements to the ideal Agile contract:
1. Deliverables are identified as business objectives that are measurable: For example, “the solution will increase staff output by 30% within six months of its release.” The words in italics are what differentiate Agile contract deliverables from those in standard software development agreements:
• Identifying business objectives focuses the agreement on the bottom-line benefits that the solution needs to deliver to the organization, not the specific features of the delivered software. It allows the customer and the project team to work collaboratively to determine the best solution to achieve the stated objective – and, most importantly, it provides the team with flexibility to adapt the solution as new technical, organizational and market information emerges.
• Working with measurable deliverables assures the client that determining the successful fulfillment of the contract work will not be left to the discretion of any one party. The measurable results can be based on quantifiable KPIs (such as the revenue generated or the operational cost savings) and/or qualitative measures (such as surveys that measure user satisfaction). The critical component is identifying the measures of success upfront, and keeping these goals at the forefront of the minds of the project team as work is undertaken.
2. The process is detailed, 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 processes 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. The process described in the contract should also identify the Agile communication channels that will be in place, and how the status of ongoing development work will be shared with the client. Note that, if your department has integrated Agile work into the organization’s QMS documentation, the details describing your Agile processes may already be available for use in these contracts.
3. Pricing is structured by iteration: Most standard IT contracts structure payment milestones around:
• The completion of software development life cycle (SDLC) phases (e.g. 20% upon completion of requirements analysis, 30% upon completion of acceptance testing), or
• Around the acceptance of pre-defined deliverables (such as 40% for the data entry screens, 30% for the automated reports).
As Agile work is designed to complete the full SDLC for the subset of capabilities being delivered in each iteration – and as the use of pre-defined deliverables defeats the very purpose of Agile approaches – the ideal Agile contract should structure payment milestones around the completion of work per iteration. This allows the client to tie payments to delivered business value without constraining the work to fit within a prescribed traditional IT payment model. As indicated in Chapter 14: Budgeting for Agile Work, the total value of the contract can be subdivided into an agreed number of iterations, with payment tied to the completion of specified iterations (i.e. one four-week iteration for monthly payments, three four-week iterations for quarterly payments).
4. Flexibility is built in 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:
• Delivery dates, and
• Status reporting mechanisms
so that the agreed Agile approach is not unduly constrained by predefined contract terms that contravene the process; for example, it is important to keep flexibility to adjust delivery dates to correspond with the client’s decision to release a subset of high-priority functionality.
It is important to note that the “ideal” Agile contract structure does not negate the need for organizations to apply due diligence in their agreements by including standard contract terms and conditions. Termination clauses, payment terms, confidentiality clauses, intellectual property terms, etc. 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.
Although having a contract that reasonably accommodates Agile work is the ideal, it is also a relatively rare occurrence in the IT industry. Most IT contracts are structured around traditional project approaches, with predefined scopes, budgets and timelines; and very few of these contracts provide sufficient flexibility to allow for mutually agreed alternative approaches to be used.
If you have already signed – or are about to sign – a traditional IT project contract, the first thing that you will need to do is check for where the contract allows for acceptable variations, such as mutually agreed amendments to contract terms, or terms in the attachments (e.g. work orders) superseding terms in the contract body. If the contract does allow for variations, then the challenge for you will be to sell to the client the benefits of Agile approaches in order to amend the existing contract – or to structure the new contract so that it allows for this flexibility. (As a last resort, you could propose to the client that the current inflexible contract be terminated and replaced altogether, but it is extremely unlikely that a client would be willing to do that!)
The reality is that you will most likely be retrofitting your Agile work into a less-than-Agile contract; in which case, the following guidelines may assist you in overcoming this challenge:
• If the contract has specified delivery date(s), ensure that Agile work outputs are aligned to these timeframes, even if one final date in the contract actually represents multiple iterative deliverables.
• If the contract has specified costs, structure your Agile teams and iterations to work within the allocated budget, as identified in Chapter 14: Budgeting for Agile Work. Ideally, you can negotiate with the client to prioritize and scope work to fit within a specified number of iterations.
• If the contract has a specified scope, particularly one defined at a detailed level, you will need to work with the client on the best way for you to jointly address this constraint. If the client is truly aware of the benefits of Agile approaches, they will appreciate that this constraint is actually limiting their flexibility to respond to the capabilities that your team delivers. If you have the client on board, there are a few ways to address the pre-defined scope constraint, including:
Agreeing with the client to establish functionality trade-offs, where higher-priority capabilities that emerge from Agile processes are delivered in lieu of selected capabilities that were listed in the original contract
Agreeing with the client to redefine the pre-defined scope to be more high-level (i.e. based on strategic outcomes), with flexibility for the details of the deliverables to evolve as work progresses
Amending the contract to describe the detailed scope as “indicative” capabilities, with reference to final delivered capabilities as agreed with the client.
Although fitting Agile work in a traditional contract can be frustrating, it can also be an opportunity for you to introduce clients to the benefits of using Agile approaches for work that was originally structured around a traditional project approach. Over time, a client who becomes more comfortable with the value of Agile approaches may be willing to accommodate more flexible arrangements in future contracts.
Agile work can absolutely be undertaken within contractually driven time, budgetary and scope constraints. Whether you have the flexibility to structure an “ideal Agile contract” or you are working within a more traditional contract arrangement, the key is to retrofit the Agile work to meet whatever constraints are defined in the contract – not to forego the opportunity to use Agile approaches due to the contract restrictions.
Inevitably, there will be situations in which an existing contract is defined with extensively detailed capabilities, and with no flexibility to adjust work as it progresses. If the client cannot be persuaded by the benefits of Agile approaches – and if they are genuinely unwilling to consider provisions that allow these approaches to be used in the project work – then you may have to make the decision to use selected Agile practices internally (such as daily stand-up meetings, so that your team can at least benefit from working in a high-communication environment). Alternatively, you could take a calculated risk of using Agile approaches regardless of what the contract stipulates, in the hope that, once the client sees the benefits of these approaches, they will be willing to consider amending the contract. In this situation, however, it may be best for you to relegate this project to traditional methods, and focus your efforts on negotiating Agile work with other clients.