1. How to Draft in the Age of Agile vs
How to Draft in the Age of Agile vs. Waterfall: Drafting Agile Contracts and Managing Risk
2016 IT.Can 20th Annual Conference
Joel Ramsey, Partner
October 25, 2016

2. Drafting Agile Contracts

3. Types of Contracts Agile methods can limit the predictability of:
Scope
Timelines
Cost
We recommend using a Agile-specific contracting template – standard contracts are typically structured to reflect the linear approach of waterfall, distinct development phases and a longer, usually singular, delivery of software

4. Types of Contracts
The prevailing form of contract is an Agile contract with a fixed price, including:
fixed price per iteration
fixed price per user story
fixed price for an agreed number of user stories
Time and materials contracts are also used, but critics argue that Agile contracts based on time and material are only suited to fairly small projects with a limited applicability to large projects
The Customer will likely seek a fixed price while Suppliers often want to work on a time and materials basis. Cost uncertainly will be the main issue from a Customer perspective. Revenue recognition will be a key issue from a Supplier perspective.
Traditional software development contracts may still be well suited to less complex projects where the Customer knows exactly what he/she wants

5. Challenges for Lawyers
Determining which terms should be binding
Describing and agreeing on the scope without certainty
Accurately describing the detailed process requirements
4. Allocating duties and responsibilities when parties are collaborating closely
5. Allocating risk and liability when parties are collaborating closely
6. Agreement on quality and acceptance/interim acceptance
7. Agreement on pricing
8. Termination and consequences

6. Acceptance
Accounting for acceptance with continuous iterations is a challenge. The follow provisions can be used to maintain some control:
minimal viable product (“MVP”)
cap costs at specific stages or Sprints or link payment to the MVP
include a longstop date for the project
Consider the “Definition of Done” – determining when a potentially “shippable” product is achieved in each Sprint.

7. Warranties and Indemnities
The collaborative and iterative nature of Agile methods create unique considerations
Since the functional specifications are not completed at the outset as in traditional software development, a description of the completed product will need to be created that can be used as the basis Supplier warranties
The development team can be comprised of Customer and Supplier personnel or Supplier personnel only. If Supplier personnel only, the indemnities given will be comparable to a traditional contract. If Customer personnel are involved, there will be difficulty discerning the allocation of risk and liability between Customer and Supplier

8. Liability
The contract will address limitation of liability using similar concepts as a traditional development contract, but the structure will depend on the overall contract structure
Beyond the usual overall cap on Supplier’s liability and carve outs, consider liability for project delays (to be distinguished from delayed payment):
if an overall project timetable is agreed to, in addition to timetables used for iterations (and it is possible to allocate responsibility for delays), then a liquidated damages for missing one or more key milestones
however, the agile methodology and iterative nature of Sprints makes it less critical to focus on legal remedies than on following the process

9. Termination
In addition to standard termination provisions, it is common that the Customer insists on having the right to terminate after each Sprint or specified groups of Sprints – but query whether this is a termination right or simply non-renewal
Be sure the contract addresses the delivery of work-in-progress and the Product Backlog to the Customer including software code
Make clear if and when any compensation will be payable to the Supplier if the contract is terminated early
The Customer will not want the Supplier to have a reciprocal right to terminate at the end of each Sprint (or other form of iteration)

10. Intellectual Property
The issues are generally similar to traditional software contracts (ownership and licensing rights), except that the regime will need to reflect the delivery of product in increments
An additional concern is how to practically protect IP in the context of Agile when the development is incremental – i.e. when it is “done”
The collaborative nature of agile development may also limit the ability of Suppliers to give comprehensive IP reps
Lack of up-front documentation also makes protecting IP difficult
Consider establishing rules for the source of pre-existing IP

11. Governance & Dispute Resolution
Detailed governance provisions are essential
Agile development relies heavily on governance-type structures
A fast and effective dispute resolution procedure is important given the collaborative nature of Agile projects
The contract should encourage informal discussions by the parties with clear and realistic escalation procedures up to senior management
Where informal discussions are ineffective, consider:
an independent expert to resolve technical or financial issues
mediation
arbitration or court proceedings as a last resort

12. Managing Risk

13. Refresher – Certain Key Principles* of Agile
Early and continuous delivery of useful software – working software is delivered frequently (weeks, not months)
Welcome changing requirements, even in late development
Close, daily cooperation between business people and developers
(*There are twelve Agile principles. Due to time restrictions, we are emphasizing these three.]

14. Managing Risk
Well-informed risk-benefit analysis prior to the RFP stage
Clearly articulated objectives/purpose
Closer attention to detailed and well-documented governance and dispute resolution provisions and process schedules
Clearly articulated and detailed day-to-day management and control of project by the parties
Clear allocation of responsibilities and the role of the service provider
Detailed requirements for the key project roles
Detailed requirements for the key planning and management meetings

15. Managing Risk
Ensure the Product Owner, who is a representative of the Customer, is experienced
Ensuring Customer personnel, if involved, can dedicate enough time to their roles
Early supplier engagement is important
Follow the process
FOLLOW THE PROCESS

16. Managing Risk – Enterprise Strategies for Customers
When to use Agile vs. Waterfall
Agile:
clear product vision or project objectives (even if details of scope and requirements are uncertain)
need for speed to market
incremental end-user testing is an asset for development of the product
Waterfall:
predetermined scope, requirements and timeline
low risk tolerance or margin for error
little experience with agile or still learning how to do it

17. Managing Risk – Enterprise Strategies for Customers
Customers will want to integrating Agile into RFP processes build relationships with trusted suppliers – ideally a form of Agile contract will be attached to the RFP as an appendix
Building long-standing relationships with Agile development teams will be beneficial – consider starting new vendors on small projects.
Customers should considering developing a process for determining whether a particular project is suitable for Agile based on risk characteristics – size of engagement, importance of IP ownership, liability issues