Agile is emerging as the prevailing methodology for software development. According to the 12^th Annual State of Agile Report, a survey conducted by VersionOne and published earlier this year, 97% of respondent organizations practice Agile development methods, while 52% reported that more than half of the development teams in their organizations are following Agile practices.

Agile is being used in a variety of contexts, ranging from ongoing enhancements of legacy applications to large-scale development and implementation of new applications. In addition, many companies are scaling up Agile practices on an enterprise-wide basis in areas that extend well beyond software development.

There are a number of compelling reasons why companies are adopting Agile, including:

• Faster time to market with new features and functionality;
• Improved business/IT alignment;
• Enhanced ability to manage changing priorities;
• Increased productivity;
• Higher quality software;
• Better delivery predictability; and
• Project visibility.

The adoption of Agile is not confined to in-house activities. Over 45% of respondents to the VersionOne survey reported using Agile practices to manage outsourced development projects with 40% citing plans to increase the use of Agile in outsourced projects during the next 24 months. Some major software licensors are also encouraging their licensees to use Agile in implementing their products. For example, SAP replaced its ASAP methodology with SAP Activate, an Agile methodology, for S/4 HANA ERP implementations.

This means that companies will need contract templates that are suitable for Agile development. However, most software development contracts in use today were designed for Waterfall projects.

As illustrated below, Agile is a fundamentally different approach to software development than Waterfall.

Contract templates designed for the fixed scope, sequential approach to development embodied in the Waterfall methodology need to be modified to adapt to the flexible, iterative nature of Agile development while preserving an appropriate level of accountability of suppliers for their performance. Below we highlight some key areas in which contract templates need to be adapted for Agile.

Agile Framework. There are a number of different Agile frameworks, the most common being the Agile Scrum method. In addition, there are several methodologies to scale Agile development for large projects, portfolios and value streams, such as the Scaled Agile Framework (SAFe). In preparing contract templates for Agile, it is important to understand which Agile framework the company is adopting (including any company-specific variations to the framework) so that the contract properly reflects the terminology and practices of that framework.

Agile Process Description. The contract should describe the Agile process in reasonable detail, including the following elements:

• Agile team composition, staffing and roles;
• The overall vision of the project and the process for creating, prioritizing and updating the product backlog of user stories to be developed during the project;
• Iterations (or sprints) during which user stories are developed;
• Key meetings (or ceremonies) that drive and support the iteration cycle, including product backlog refinement, iteration planning, daily scrum, iteration review, iteration retrospective and release planning meetings;
• The process for estimating the size and complexity of user stories in the form of “story points”;
• The process for defining when a user story is considered to be complete (the “Definition of Done”);
• The involvement of business owners and stakeholders throughout the project;
• The tracking and monitoring of progress through burndown charts, burnup charts, task boards and the like;
• The process for releasing and deploying working software into production; and
• A description of what constitutes project completion.

Acceptance. The “Definition of Done” captured in the Agile process description is the analog to Waterfall’s software acceptance procedures. In Agile, acceptance of working software occurs initially at the end of each iteration (e.g., every two weeks), and ultimately at the release level, with a determination by the Product Owner of whether the software meets the Definition of Done. In contrast, the acceptance process in Waterfall typically occurs at the end of the project and involves formal acceptance testing of large sets of code at one time. This “one-time, end of project” formal acceptance procedure of Waterfall needs to be modified in the contract to reflect the more frequent, incremental acceptance process of Agile.

Warranties. In Waterfall, the supplier warrants that its work product will conform to the specifications and requirements defined in the SOW (and any Change Orders) for a warranty period typically in the range of three to 12 months following acceptance by the customer. Because Agile involves delivery of working software in short increments, warranty periods tend to be relatively short periods (e.g., 30 days) following each release. Defects identified during iterations are typically fixed by the Agile team during the same or subsequent iterations.

Service Levels. Depending on the nature and duration of the project, it may be appropriate for the contract to include a set of service levels to measure the performance of Supplier-staffed Agile teams. Key metrics may include:

• Iteration (Sprint) Completion Rate – measures the percentage of committed user stories completed during the iteration.
• Agile Team Velocity – measures the number of story points completed per iteration in terms of consistency and continuous improvement.
• Defect Density Rate – measures the quality of Agile team output in terms of the percentage of post-production defects.
• Agile Team Attrition Rate – measures the continuity of Agile team staffing by the supplier.
• Business Owner Satisfaction – measures the satisfaction of the business owners or stakeholders with the work of the Agile team(s) in terms of business value added, quality of work product and responsiveness to feedback.

Pricing Constructs. A typical Waterfall project specifies a fixed set of deliverables, supported by detailed specifications and requirements, which the supplier commits to deliver at specified dates for a fixed fee. A formal change control process is used to agree on and document scope changes. Agile is not well suited to this type of firm fixed-fee pricing due to the constant change and re-prioritization of requirements that are inherent features of the Agile process. As a result, pricing for Agile projects tends to be based on level of effort, such as straight time and materials or fixed monthly run rates based on the mix of supplier personnel on Agile teams. Depending on the nature of the project, however, there can be overlays of shared risk/reward against target costs, incentives/penalties based on Agile team velocity and other performance metrics, and even commitments by the supplier to deliver a defined minimum viable product for not more than a specified price. In preparing contract templates for Agile, companies should consider the potential pricing constructs they may want to apply to various types of development work.

Termination. By delivering and demonstrating working software at the end of each iteration, Agile provides greater visibility into the progress of software development projects than Waterfall, enabling customers to asses more quickly the effectiveness of their suppliers and quickly make desired course corrections. Suppliers benefit from a lower project risk profile by not being locked into firm fixed-fee pricing based on a set of upfront requirements that may not be well defined. These considerations suggest that the contract templates used for Agile should afford the customer a great deal of flexibility to terminate or scale down projects for convenience on relatively short notice—potentially as short as the end of the next iteration—based on the customer’s changing needs and priorities and its assessment of supplier performance.

***

As reflected above, there are a number of changes required to existing Waterfall-based contract templates to adapt them to Agile. In light of the increasing use of Agile for software development, companies would be well advised to develop their own contract templates rather than rely on supplier forms. This will help companies secure more favorable terms and achieve greater consistency in Agile practices across the enterprise for both internally and externally performed Agile projects.