Must-Haves for Agile Contracts 4


Agile contracts are a hot topic. In our recent thought paper, Sourcing for Agile, we discussed the challenges of sourcing software development services where speed and agility is key, and we discussed different management and development methodologies that have been tried to smooth and empower the relationship between the customer and supplier. All too often they have failed because of a rigid adherence to templates, processes and procedures that hinder customers and suppliers from adapting to the speed of change present in competitive commercial environments.

The manifesto captures the essence well: Customer collaboration over contract negotiation.  Accordingly, there is much value in contract negotiation for all parties, but ensuring that it does not damage the ability to collaborate is paramount.

In 2010 Emergn developed the industry’s first agile contract template along with a leading law firm. The result was a set of principles that could be applied in helping shape the contractual agreement between a client and their supplier all for the purpose of improving the relationship in terms of expectations and outcomes. While no single document can solve relationship challenges, a value-based agreement can help influence behavior and remove some of the barriers to making the relationship more fluid and meaningful, as many clients have experienced thus far.

Below I’ve highlighted some of the “must-haves” in an agile contract and inserted some excerpts from the contract template to share and demonstrate what this might look like.

  • Commitment
    • The contractual commitment is for the amount of the output (in the form of fully working software that is ready to be deployed) rather than the detail of the output (i.e. the actual specifications). This represents a real departure from the traditional fixed price contract or contract based on time and materials, and opens up a number of innovative pricing models.

 “8.1 Planning:

(a) The parties shall conduct the Planning for the Release (i) at the start of the Start-Up Phase, (ii) at the start of the Calibration Phase and (iii) following the execution of the SOW for each Release in the Operational Phase.

(b) Each of the parties shall ensure that the following persons attend the Release Planning in person: (i) on behalf of the Supplier: all members of the team or key individuals who are fully empowered to act on behalf of the members who they represent; and (ii) on behalf of the Customer: the Product Owner.

(c) The Supplier shall re-assess the number of Story Points for each Story as set out in the Product Backlog and shall confirm the actual number of Story Points for each Story that will apply in respect of that Release, all in accordance with the Methodology.

(d) The Customer shall re-assess the Story Value for each Story as set out in the Product Backlog and shall confirm the actual Story Value for each Story that will apply in respect of that Release, all in accordance with the Methodology. “

  • Specification
    • There is no need for an up-front specification because the contractual commitment is for the amount of output rather than the detail of the output. This greatly reduces the time taken to negotiate and manage the contract.  Jointly working on the specification throughout the project is built into the approach.  There is a provision for building high-level value cases so that good trade-offs can be made throughout the project.

“(c) The Product Backlog: This contains an initial list of the Stories together with (i) an initial indication of the Story Value in accordance with the Methodology for each of the high priority Stories; and (ii) an initial indication of the Story Points in accordance with the Methodology for each of those Stories with a high Story Value, as provided by the Supplier.”

  • Capacity
    • Capacity is measured in terms of fully working software, capable of being deployed, that incorporates features as specified by the customer. It is only when this is delivered that the customer receives real value. Reports, updates and deliverables are no substitute for fully working and tested software.

“(c) The Supplier shall re-assess the number of Story Points for each Story as set out in the Product Backlog and shall confirm the actual number of Story Points for each Story that will apply in respect of that Release, all in accordance with the Methodology. “

  • Feature Prioritization
    • Mechanisms for prioritizing the features to be worked on have been introduced. One of the greatest forms of waste – building features that are never or rarely used – is eliminated.

“(e) The Customer shall prioritize the Stories which are to form the subject of the Release Plan, taking into account Clauses 8.1(c) and 8.1(d) and the feedback from the Demonstration for the previous Release (if applicable). “

  • Feature Change
    • Any changes in the features over the term of the project can be accommodated because the features to be built are only committed to at the start of each iteration. So there is no need for cumbersome, resource-intensive contractual change control mechanisms.

“7.6 The Customer may amend the Stories that are comprised within the Minimum Marketable Features of a Release at any time during the Release at no additional charge provided that:

(a) The Customer shall not be entitled to make any changes to the Stories that form the subject of an Iteration following the mutual agreement by the parties of the Iteration Plan for that Iteration; and

(b) New Story(s) and/or variations to existing Story(s) may only be introduced if (i) existing Story(s) with an equivalent number of Story Points are removed or (ii) existing Stories are reduced in size by the equivalent number of Story Points, such that the total number of Story Points for the Release remains constant throughout the Release. “

  • Metrics
    • There is a great emphasis on delivering features fast. Metrics are incorporated into the contract to review the level of productivity of the parties and to give the parties the necessary information to make improvements in the feature cycle time – that is, the time from conception to delivery of a feature.
  • The Software is Done
    • Testing is an integral part of the design/development process, which is used to provide valuable feedback and build in quality, rather than simply arm the customer with contractual rights and remedies.

“9.6 A Story shall be deemed to be “Completed” and shall constitute a “Completed Story” when each of the following applies to that Story:

(a) The Solution has successfully met the Acceptance Criteria for that Story;

(b) The Solution has completed the testing processes as set out in the Methodology and has passed such testing processes;

(c) The Software in respect of that Story is ready to be deployed to a pre- production or production environment, and the Software is capable of being repeatedly deployed to any number of target settings within a pre- production or production environment, such that the operation of the Software would be consistent across each of the target settings regardless of the nature of such target setting;

(d) The Deliverables as set out in the Methodology have been approved by the Customer in respect of that Story;

(e) The Product Owner and the Customer Representative have confirmed that the Story has been satisfactorily completed. “

  • Code Quality
    • There is much greater emphasis on the quality of the code built. Metrics that look at the accuracy of the code, its degree of robustness and the ease with which the code can be maintained are all built into the contract.
  • Risk/Reward
    • The risks and rewards of the project are shared and aligned to the skills, competence and expertise of both parties.
  • Shared Delivery Model
    • The shared approach to the delivery model allows both parties to bring their innovations and experiences to the project which can be continuously improved as a result of the transparency and feedback built into the contract.

“7.4 In respect of each Release, the Supplier shall deliver the Solution resulting in the Completion of Stories with an associated number of Story Points that is equal to or greater than the number of Story Points set out in the SOW by the Release Completion Date, provided that the Customer performs its obligations under the Agreement.

7.5 The Customer acknowledges that if it does not perform its obligations under the Agreement in respect of a Release, this will have an adverse impact on the number of Story Points that the Supplier is capable of Completing within that Release. Accordingly, if in respect of any Release, (i) the Supplier fails to deliver the Solution resulting in the Completion of Stories with an associated number of Story Points that is equal to or greater than the number of Story Points set out in the SOW by the Release Completion Date and (ii) the Supplier can demonstrate that the reason for such failure is directly caused by the failure of the Customer to perform one or more specified obligations under the Agreement:

(a) The Supplier shall cease to be bound by the obligation set out in Clause 7.4 for that Release; and

(b) Clause 12.3 shall not apply in respect of that Release. “

  • Vendor & Sourcing Evaluation
    • The need for an evaluation of existing vendor relationships and sourcing processes are identified so that the implementation of an agile contract is optimized across the organization. Managing the Relationship is built into the joint way of working so that problems in the delivery of working software are discussed regularly and improvement plans are jointly agreed to and continuously implemented.  What is built, how it is built and each parties roles and responsibilities are inextricably linked.
    • The great thing about most agile methods is that they work with a cadence that encourages continuous assessment and improvement.  The most common form of such review is the retrospective and can be used more frequently to evaluate the overall relationship and make sure that the value of the work outweighs the costs for running the team and the relationship

“9.7 Retrospective:

(a) The parties shall conduct the Retrospective for each Iteration following the completion of the Demonstration for that Iteration.

(b) Each of the parties shall ensure that the following persons attend the Retrospective in person: (i) on behalf of the Supplier: all members of the team or key individuals who are fully empowered to act on behalf of the members who they represent; and (ii) on behalf of the Customer: the Product Owner and the Customer Representative.

(c) The Supplier shall provide the Customer with the reports set out in Clause 11. The Customer shall review the Metrics for the performance of the Activities during the Iteration as detailed in the reports.

(d) The parties shall discuss how and why any of the target and/or Contractual Metrics were not achieved (if applicable), which aspects of the Activities went well, which aspects of the Activities did not go well, taking into account the people, process and tools used in the Iteration; and the parties shall address areas for improvement and produce an action list for redressing such areas in the next Iteration and/or Release (as appropriate).”

Traditional contracts are under scrutiny and for many organizations are simply not producing results or the behavior needed to manage the speed of change and the challenges of cost constraints and evaporating budgets. Agile contracts are simply value-based agreements that take into account the working principles that companies want to see in effect between themselves and their suppliers.

They help shape the story and build in the right level of flexibility to accommodate change, manage quality and costs and ultimately help underpin the “agile transformation” many are looking to get to.

4 comments

  1. As a long-time consultant who has seen the value of agile for both the customer and the developers, yet struggled with how to manage the legal aspects of the engagement, I found this post to be extremely helpful. As more customers come to realize the agile processes give them the best hope for success, these sort of contracts will become more common.

  2. Great article. Having watched the long process of negotiating and signing “agile” contracts many of which resulting in rigid contracts, with incorrect measures of success, I feel this is a great starting point going forward.

  3. Pingback: Distributed Agile: Past and Present « Alex Adamopoulos

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s