Agile software development methodologies are hardly new. But figuring out a way to adequately contract for them in IT outsourcing deal is.
“Under traditional contracting approaches, there is an assumption that the development team can define, with some specificity, the ultimate ‘thing’ to be created supported by a detailed project plan and key milestones tied to client acceptance and financial payment triggers,” says Derek J. Schaffner, attorney in the Washington, D.C. office of law firm Mayer Brown. “These concepts are very easy to memorialize in a development agreement due to the linear nature of a traditional software development approach that commences with detailed planning, followed by design, coding, testing and deployment.”
[ Keep up to date with the 7 hottest IT outsourcing trends — and 7 going cold. | Get all your outsourcing questions answers with our outsourcing definitions, best practices, challenges and advice. | Get the latest outsourcing and IT strategy insights: Sign up for our CIO newsletter. ]
Agile software, however, rejects traditional software processes in favor of more fluid development. “There are no detailed project plans or key milestones because the client and developer continually evaluate and prioritize activities in short iterations or sprints,” Schaffner says. “An agile software development approach requires a leap of faith by clients who are accustomed to the formality and control of traditional software development.”
However, there are contractual mechanisms that clients can implement to reduce uncertainty while still reaping the benefits of this more collaborative development method. CIO.com talked to Schaffer about how to implement protections in agile outsourcing deals.
CIO.com: What are the biggest challenges in drawing up contracts for agile development deals?
Derek J. Schaffner, Mayer Brown: An agile software development approach emphasizes unstructured, continuous interactions between the client and developer based on trust and understanding, which are difficult to memorialize in a contract. The biggest challenges involve creating a framework to take advantage of agile’s creative benefits while balancing the need for client to have the software built in a timely manner for a fair price.
CIO.com: So fixed price deals are out. How should clients approach pricing when developing an agile deal?
Schaffner: The agile software development [ASD] process more naturally fits a time and materials (T&M) model, which understandably makes CFOs and CIOs nervous. After all, ASD requires a leap of faith — specifications are not clearly defined and there is a pricing model that motivates the developer to charge as many hours as possible.
There are variations of the T&M model that can help control costs, such as capped T&M on an iteration or project basis, a ‘holdback’ for each iteration that accrues but is not paid to the developer until the entire project is complete, and a pool or bucket of development hours paid on a fixed basis that the client can spend as it desires.
The T&M model is more palatable due to its more client-friendly termination rights. However, there is a huge risk here: once the project is sufficiently far along, the client’s desire to complete the project outweighs the flexibility to easily exit the project. This could create a situation for the developer to gouge the client towards the end of an agile software development project unless there is a cap on fees.
CIO.com: So how do termination rights work in these situations?
Schaffner: Given that the goal of each iteration is to produce workable code paid for on a T&M basis, the typical agile software development agreement allows the client to terminate the project at the end of each iteration usually without the payment of termination charges. If the client does not see value in the work product produced during the latest iteration, it can simply walk away. The chance that a project goes dramatically astray during an iteration is minimal because the requirements for that iteration are always defined at the outset of that iteration, which presumably advances the larger goals of the ‘thing’ being built in accordance with the product vision.
However, the agile software development approach involves minimal software documentation, so resituating a terminated project at a later date may be more costly since new developers will need to spend more time diving into the code before work can resume.
CIO.com: Agile development is, by definition, fluid. How can customers build some milestones into a contract at the outset?
Schaffner: The ASD approach begins with a high level concept of the product to be developed (the “product vision”). Using the product vision as a guide, the development team then creates a statement of requirements (the “product backlog”), which essentially is a list of prioritized items to be developed during the project. The development agreement should specify how the product backlog will be managed during the project, including obligations for the developer to provide cost estimates to develop each item in the product backlog. The parties can then use the prioritized list of items from the product backlog to determine the order in which items will be worked.
If the parties decide to exclude the initial product backlog as a contractual document under the development agreement, the parties should specify in the agreement how the product backlog will be developed and prioritized. The client should also have the sole and exclusive right to amend and reprioritize the product backlog.
An agile software development agreement should also define the iteration process, including the duration of each iteration (usually not to be extended; unfinished work rolls into the product backlog and is prioritized), the meeting cadence, and the process the parties will use to determine when the work in an iteration is done. Note that rolling unfinished work into a subsequent iteration may have a price impact though.
CIO.com: How can customer mitigate the risk of employee turnover on these projects, which depend on more continuity?
Shaffner: While the iteration approach provides a client the ability to easily terminate a project, [providers] may be less likely to commit developer resources on a long-term basis unless the client makes a financial commitment to use those resources. TO mitigate this risk and the subsequent loss of project knowledge, the client should name a few key developer personnel whose commitment to the project is memorialized in the agreement with assurances from the [provider] that these resources will not be moved off the project without approval from the client.
The agreement should also contain assurances that the developer will provide all the resources necessary to complete the tasks in a given iteration, thereby removing the potential excuse that an iteration could not be finished due to lack of resources. Finally, the contract should specify that knowledge transfer activities among developer personnel are not chargeable.
CIO.com: In traditional application development outsourcing, the provider warranties that the product meets specifications and that it will remediate any failure to perform in accordance with those specifications for a period of time. Can you do that with agile-developed software?
Schaffner: Offering a warranty like this is a bit problematic, but the developer could warrant that the working code produced during each iteration meets the specifications for that iteration. As more working code is built in subsequent iterations, the client should seek a warranty from the developer that the integrated pieces will work together, and that the final product will perform in accordance with the summation of the specifications from each iteration. The client should also evaluate whether or not there is some seasonality associated with the product and ensure that the warranty sufficiently covers periods of high demand or use.
CIO.com: How should IP rights be handled in what is a more collaborative process between client and provider?
Shaffner: An agile software development agreement should clarify which party owns the intellectual property rights in the developed product and whether the other party has a license to use and/or create derivative works of the developed product. If the [provider] insists on owning the intellectual property rights, the client should have an unrestricted license to the developed product and potentially seek restrictions on the developer’s use of the product within the client’s line of business. The situation is further complicated if either party brings pre-existing code to the project, which may require case-by-case negotiations.
CIO.com: If a client is struggling too much trying to write a satisfacotry agile development agreement, might it be a sign that outsourced agile isn’t right for them?
Schaffner: Contracting for agile software development requires a client to give up a certain amount of control and contractual remedies to enforce if the project goes astray. The challenge involves contracting for trust, which many organizations — and lawyers — struggle with. Until clients are more comfortable with the lack of control and price variability, the traditional approach be better for the development of mission-critical applications.
Related outsourcing articles: