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

Drafting Agile Contracts

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

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

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

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.

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

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

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)

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

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

Managing Risk

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.]

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

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

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

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