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.”
[ Related: Making the case for agile in the enterprise ]
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 (TM) 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 TM model that can help control costs, such as capped TM 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 TM 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 TM 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.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.