Three Contract Models for Scrum Projects

Tags: agile, scrum, contracts

In this post I want to do a high-level fly-by of the options you have to establish a contractual relationship for your next agile project.  Moving toward an iterative/incremental delivery process requires rethinking not only your software delivery practices but the legal framework that will enable them.  As you may have discovered, traditional contracts are by definition inflexible agreements intended to apportion risk exposure in an adversarial relationship.  Contractors are obliged to "make the date/cost" irrespective of the hurdles thrown in their way, while customers are dissuaded from making any changes mid-stream (irrespective of merit) through costly change order processes.

Obviously, this is the antithesis of agile software delivery which relies on an agreement that promotes a collaborative relationship between contractors and customers to promote sharing of risk with flexible options for accommodating changes while controlling scope.  The following contracting models are an intermediate step toward this ideal; they re-balance  the contractor/customer relationship by giving customers options for controlling scope and costs in exchange for agreeing to a covenant to abide by the rules of Scrum - which is mutually beneficial. In the case of Mitch Lacey's Ranges and Changes model, risks and latent knowledge are surfaced with a short, two-week exploratory project that can be used to prime an agile project with a preliminary Product Backlog and Release Plan.

Each model starts with using a standard fixed-price contract that includes time and materials backstopping as a starting point, thus addressing contractor risk exposure, and adds on options to accommodate changes and costs, thus addressing customer risk exposure. In turn, these provisions act as legal "interfaces" into Scrum, which governs project delivery on a day-to-day basis.

While these are great options for getting your customers to buy-in to a Scrum project, they should be considered waypoints in a journey toward an entirely different relationship management framework called alliancing, which my friend Paul Culmsee outlines in his recent book with Kailash Awati, The Heretic's Guide to Best Practices.  However, this is a story for a subsequent post.  As they say, "Start Here" and see where it leads.

As always, comments/suggestions/slings/arrows are welcome in the comments below or via Twitter at @DerailleurAgile.

Change For Free

Created By:

  • Jeff Sutherland, Scrum Co-Creator

In Brief:

  • Combines a standard fixed-price contract with an option for customers to make changes in scope (features) without incurring a penalty.

Key Feature:

  • Change for Free option clause that may be exercised by the customer to make changes in scope without penalty provided that they adhere to the rules of Scrum for each iteration by fulfilling the role of Product Owner and working with the team. In all other instances, changes are charged according to time and materials.

How it Works:

  • Per Scrum rules, the customer Product Owner is responsible for re-prioritizing their Product Backlog of features according to business value at the end of each iteration. Changes in the backlog's priority are free provided that the total contract work is not changed.  New features may also be added for free during Sprint Planning or Sprint Review in exchange for an equal sum of low-priority features.

Customer and Contractor Obligations:

  • The customer must agree to abide by Scrum Rules and keep their Product Backlog in priority-order and involve their stakeholders and end-users to ensure that only the most valuable features are developed.
  • The contractor must provide assistance to the customer to help them build their Product Backlog and facilitate working with the development team under Scrum rules of engagement.



Money for Nothing

Created By:

  • Jeff Sutherland, Scrum Co-Creator

In Brief:

  • Adds an option to Change for Free contracts that allows customers to terminate a project at any time for a nominal charge of 20% of the remaining contract's value.

Key Feature:

  • Money for Nothing option clause that may be exercised by the customer for early termination of the contract provided they adhere to the rules of Scrum, otherwise remaining work to meet the cutoff is assessed using time and materials charges.

How it Works:

  • The customer may, at any time, decide an ROI-cutoff point, ie. the point where the cost to develop the next feature or set of features in the backlog exceeds the value to the business.  Accordingly, the vendor agrees to terminate the project for 20% of the remaining contract value while assuming the risk of late delivery for any mutually-agreed upon features to meet the ROI-cutoff.

Example:

You have agreed to a $100,000 contract with a number of features that are being developed across eight sprints/iterations.  During development on the sixth sprint, the customer decides that they should have enough features to release the software by the end of the seventh sprint.  They request a meeting with the Scrum Master and their manager to announce the invocation of the Money for Nothing option.

Once it is confirmed that the customer has met their obligations and is greenlit for the option, the team is informed that this will be the final iteration and they are committed to complete the work that will be mutually estimated and agreed to for sprints six and seven as per usual Scrum rules and options.

With each sprint costing $12,500 ($100,000/8), the remaining value of the cancelled project for the last sprint is $12,500. After invocation of the Money for Nothing option, the customer retains 80% of this value ($10,000) with the 20% balance ($2,500) going to the vendor.  

Thus, the total cost of the contract to the customer is $12,500 * 7 = $87,500.00 + $2,500 = $90,000.00

Customer and Contractor Obligations:

  • The customer must agree to abide by Scrum Rules and be a full-participant in their project;
  • The contractor must agree to the terms of the Money for Nothing clause, including the reasonable assumption of risk for features to meet an arbitrary cut-off date. This necessitates having good software engineering practices that keeps the software in a potentially-shippable state at the end of each iteration.



Ranges and Changes

Created By:

In Brief:

  • A two-part contract consisting of a discovery phase designed to provide customers with ballpark cost and date ranges for a preliminary set of features which can then be used to determine if it makes sense to proceed with a delivery phase using a Money for Nothing/Change for Free contract.

Key Features:

  • A Discovery Project Contract for a short, fixed-length investigation of a customer's software requirements and build a preliminary Product Backlog that is assessed a range of estimated costs and dates according to team size and expected velocity in story/feature points. This project should include enough funding for 2-3 developers for two weeks. Deliverables include an estimated Release Plan and Product Backlog along with an expected minimum number of feature/story points that the team could deliver based on the investigation.

  • A Delivery Project Contract that references the Discovery Project Contract deliverables and establishes a framework for delivery using the estimated ranges as a starting point. Also includes the team's Definition of Done to deliver each feature, how the work will be delivered and an explanation of how the customer can reject an iteration's worth of work.  This contract will likely include the Money for Nothing/Change for Free options detailed above.

Customer and Contractor Obligations:

  • Same as with the Money for Nothing/Change for Free contracts;
  • Contractor agrees to provide all deliverables from the Discovery Project to the customer;
  • Customer agrees that all estimates derived from the Discovery Project are extremely preliminary and can be expected to change when implemented in a project.

See Also:

  • This contracting arrangement is discussed in-detail in Mitch's excellent book that I've linked above.
blog comments powered by Disqus