/*

Agile Contracts

/*

Agile Contracts

March 13, 2016
Photo of an agilist filling out an agile contract.

An agile project is likely to look drastically different as compared to a waterfall project. As a result, the contract for an agile project needs to be constructed with mutual understanding of these differences between customers and organizations practicing agile. Acknowledging the unique project environment in the agile contract will allow both sides to better support their agile projects. In this post, we describe key features agile contracts need to have and describe a few examples of contracts.

Key Features of Agile Contracts

Three things are needed for a procurement relationship: a buyer, a seller, and a contract. Through the contract, the buyer and seller establish a common understanding of the deal and what each side will get out of it. Contracts are meant to set the rules of engagement, share risk, and build trust. With the flexible and unique environment of agile, what key features need to be included in an agile contract so that both sides can benefit from the agile process?

  1. Flexibility. On an agile contract, flexibility takes two forms. First is flexibility of scope, which when established, allows the team to work on the highest-priority backlog items with understanding and validation from the customer. Second is flexibility of process. Teams need the flexibility to emphasize the process over the product, determine their own length of sprints, and empower the team to manage themselves. On the other hand, the contract also needs to set a minimum number of story points delivered to ensure that the customer receives value for its investment.
  2. Commitment. Agile thrives off of customer commitment and feedback. The customer benefits from increased engagement through earlier and more consistent value delivery and greater satisfaction. In the contract, the customer and team should commit to collaboration. This includes the mechanism for prioritizing the product backlog, adherence to the roles and responsibilities of the customer and team, and attendance at ceremonies, including release planning, daily scrums, and sprint review and retrospectives.
  3. Risk-sharing. As stated earlier, one of the purposes of a contract is to define the level of risk-sharing between buyer and seller. Neither side should bear too much risk. In many situations involving agile, the customer takes on greater risk early on because requirements are not defined upfront. To offset this, both sides should agree on sharing the risk of economic or price fluctuations, cost or time overruns, and unforeseen circumstances.
  4. Defined checkpoints. Because agile involves value delivery over iterations rather than all at once, an agile contract needs to have more checkpoints. Checkpoints in an agile contract should center around sprints and releases. At each sprint, the customer needs to be able to review what the team has completed and provide feedback. In addition, both sides need to agree on a “definition of done” for each task in a sprint to ensure clear understanding of when work is finished. At the release level, the customer should be able to request that the team continue to deliver the next features in priority order, to be delivered in additional sprints, or declare their satisfaction with the current work and close the project.

Agile Contract Examples

Now that we’ve explained key features that need to be present in agile contracts, we will describe three examples of agile contracts and how each benefits both the customer and the team:

  1. “Money for Nothing and Change for Free.” This contract type, created by Jeff Sutherland, is a standard fixed price contract with time and materials clause for additional work. This means that the customer pays a fixed price for value delivery and pays only for time and materials for any additional sprints.

As is, this type of contract would present more risk to the customer because of the possibility of additional sprints. However, there are two customer-friendly options in this type of contract. The customer can invoke the “money for nothing” option and terminate the contract early for 20% of the remaining value if they determine the ROI on their remaining items is not sufficient. With the “change for free” option, the customer can reprioritize the backlog at the end of a sprint, and if the total contract work does not change, these changes are free as long as the customer remains engaged in iterations. With these options, the customer is more flexible to reduce risk.

Figure 1 shows both the Money for Nothing and Change for Free options:

Money for Nothing

Change for Free

Figure 1. Money for Nothing and Change for Free Options

  1. Graduated Fixed Price. In this type of contract, hourly rates for the supplier differ based on delivery timing. If the team finishes early, the customer pays a higher rate for the fewer hours. If the team finishes late, the customer gets to pay a lower rate for more hours (Griffiths, 2015).

Figure 2 shows an example of the graduated fixed price contract. You will notice that with early delivery, the customer actually pays less overall. When the team finishes 200 hours late, they get more money overall, but at a reduced rate that is equivalent to 80 hours of the standard rate.

Graduated Fixed Price

Figure 2. Graduated fixed price contract example.

  1. Fixed Price Work Packages. This type of contract, which has been used by Marriott before, fixes a price based on work packages rather than an overall statement of work (SOW) (Griffiths, 2015). Focusing on work packages allows for smaller and more precise estimation, and both the customer and team can re-estimate based on new information once each work package is complete.

Figure 3 compares a traditional SOW to the fixed price work packages approach:

Fixed Price Work Packages

Figure 3. Traditional SOW Compared to Fixed Price Work Packages.

Conclusion

There are many other types of agile contracts. One recent example used in the Scaled Agile Framework (SAFe)® is the SAFe Managed-Investment contract, which include Precommitment, Execution, and Evaluation phases to make sure that both sides understand the agile processes that will be used.

Regardless of which of the above contract examples is chosen, agile teams and customers will have the best chance of succeeding with an agile project if the contract allows the agile process to proceed uninhibited. By setting up commitment to the process and spreading risk among both customer and buyer, an agile contract will help guide teams and customers to mutual success.

RefineM offers Agile transformation services to help teams and customers realize the benefits of agile. Need help with an Agile contract or an Agile project? We’re happy to help.

What are your experiences with setting up agile contracts? Please let us know in the comments.

References

  1. Griffiths, Mike (2015). PMI-ACP® Exam Prep. Second Edition. Minnetonka, Minnesota: RMC Publications.
Posted in Blog and tagged .