Contracting within an Agile environment has proved challenging for many organizations and as a result, there is a widely held belief that it is quite difficult to negotiate contracts for Agile work. My response to this is, while Agile contracts are somewhat complicated, they would not be so difficult if the team would walk the fine line to get it right. I say this for the reasons given below.
To effectively navigate the delicate field of Agile contracting, the team would have to start by selecting the right vendor(s). The team must be sure that the selected vendor is ready to work in an Agile environment. If it is required that a vendor uses an Agile approach to get involved in the project, this should be clearly spelt out in the Request for Proposal (RFP).
The team should use its discretion to determine if the vendor’s involvement in the project requires that the vendor understands agility. Sometimes, some vendors play a role so minor that there might not be a need to coach them on agility but for some other vendors, their role is so critical that it would be best to coach them on what it means to be Agile. Overall, the team needs to do a Cost-Benefit analysis of educating or not educating its vendors on it’s Agile projects.
If an Agile team were to attempt to use a traditional vendor contracting method, this would most likely be problematic and that is because Agile requirements often change and need a certain level of fluidity in contracting. Some examples of contracting models appropriate for Agile projects are: Fixed-Price Work Packages, Graduated Fixed-Price Contracts, DSDM Contracts, Money for Nothing and Change for Free Contracts and Customized Contracts. These contracting models will be discussed towards the end of this article.
Some of the benefits of agility, namely; flexibility and acceptance of changing requirements tend to pose a problem in contracting as it makes defining an acceptance criteria for contracts or outsourcing work difficult. Based on the three project constraints (scope, time and cost), Traditional project management has scope fixed while time and cost could be adjusted based on the project’s needs but the case is the opposite within the Agile methodology as cost and time are fixed while scope can be negotiated, this is what is known as the Inverted Triangle Model.
Agile projects allow scope to be variable because an Agile project targets creating a product that has the highest priority, highest business value and of course the highest return on investments possible for the customer in the face of competition and within the fixed constraints.
The fact that on an Agile project, scope is variable, implies that the team might end up not delivering all the product functionality. This possibility is quite unacceptable to many organizations who would prefer that a firm commitment is made based on a complete and up-front estimate of the whole product. Organisations also, understandably, prefer a written contract so they would know who to hold accountable in the event of deviations from the contract commitments. But for an Agile project to achieve the complete functionality within the constraints of cost and schedule as stipulated within the contract, extensive, tedious and costly analysis must be done, and carefully designed specifications must be produced. In addition, considerable contingencies must be included in the contract to accommodate reasonable and unexpected changes, technical issues and possible set-backs. If required, Agile customers can indeed have fixed scope and firm estimates but this will be cost intensive as the estimates will have to be inflated as a safeguard against uncertainty, the customer will also have to pay for activities that present no business value after going live.
One of the objectives of the Agile methodology is closer interaction and cooperation between the project team and the customer, this is in keeping with the third Agile Manifesto which places “Customer Collaboration over Contract Negotiation.” Close collaboration between the team and the customer helps to ensure that the team’s efforts are directed towards delivering the customer’s value adding features. The Agile methodology calls for more trust between the customer and the team than what is obtainable within a Traditional approach.
Agility also requires the customer to be closely involved in providing feedback to the team on sprint deliverables, backlog prioritization, as well as the prioritization of change requests against the remaining features to be delivered. When there is a high level of trust from a client who is also invested in the project, Agile contracts would be ideal and would deliver more value while giving such clients a competitive advantage. But in a situation whereby the client is skeptical and hands-off, Agile contracting will not be recommended.
There are a few models for Agile contracts and some of them are briefly discussed below.
Fixed-Price Work Packages
This contracting type reduces the risk of underestimating or overestimating a piece of work by reducing the scope and costs involved in the work being estimated. Using this method allows the customer to reprioritize the work left based on evolving costs. This approach also provides the supplier the room to update their costs as new information emerges while eliminating the need for the supplier to add excessive contingency funds to the project cost. The new changes are then assigned to small work packages. If it happens that there is a need for more funds, this is easily identified and can be justified.
DSDM Contract
This contract was originally commissioned by the DSDM Consortium and has continued to evolve. It is centered on work being “fit for business purpose” as well as passing tests rather than on matching specifications. The DSDM is mostly used in the UK and other parts of Europe.
Graduated Fixed-Price Contract
In this type of contract, both parties to the contract share some of the risk and reward associated with schedule variance. In this arrangement, if the supplier delivers on time, they get paid for the hours worked at the standard rate. If their delivery is early, they are paid for fewer hours but at a higher rate. But if the supplier’s delivery is late, they get paid for more hours but at a lower rate. When this occurs, both parties are rather discontented because they both make less money but at a gradual, sustainable rate that might not lead to the termination of the contract.
Money for Nothing and Change for Free
In this model, Jeff Sutherland suggests including early termination options and proposes a model that allows flexibility in making changes. Sutherland’s model starts with a standard Fixed-Price contract that includes time and materials for extra work, but he then inserts a “Change for Free” option clause.
The customer is only eligible for the “Change for Free” clause if they work with the team on every iteration/sprint. If the customer fails to be this involved, the clause is voided and inapplicable and the contract reverts to Time and Materials.
Just like the “Change for Free” clause, the “Money for Nothing” concept is equally only valid if the customer plays their part in the project. “Money for Nothing” permits the customer to terminate the project early when the customer is convinced that there is no longer sufficient ROI in the backlog items to justify additional iterations/sprints.
Customized Contracts
A hybrid of Agile contracts can be created so long as it meets the needs of the buyer and seller. The customer retains flexibility to reprioritize work with such contracts and at the same time, the seller is at liberty to share information about increased costs. Customized contracts also serve to reduce the seller’s usual inclination to add huge contingency funds to the project budget. If we combine elements of a Graduated Fixed-Price contract and Fixed-Price Work Packages and include the concepts of early termination (Money for Nothing) and reprioritization, (Change for Free), we can create a contract that protects both parties and has a productive outcome.
Furthermore, even though Agile contracts are quite beneficial to both parties, we must keep in mind the fact that creating a contract between two parties where one party wants to reduce the cost of a product or service and the other party (as a business incentive), wants to increase its profits will always require some balancing. Procurement has always been challenging on Agile projects because the details of the requirements is usually not fully defined at the onset of the project. In addition to this, the intangible nature of knowledge work projects makes it hard to estimate the work and get the necessary approval.
On a final note, any type of procurement (Agile or Waterfall) is more effective when the buyer and seller are interested in achieving a successful outcome that could lead to future work. An Agile project’s success is essentially determined by the degree of continuous collaboration between the team and the customer. While an Agile contract cannot guarantee that level of collaboration, with some work and imagination, it can be better structured to support it.