There has been a significant amount of discussion regarding the tension between development and agile contracts. Many see this conflict as irreconcilable, citing provisions in the Agile Manifesto favoring “working software over comprehensive documentation” and “customer collaboration over contract negotiation.”

Those who see the conflict this way claim that lawyers are operating in an outmoded mindset and need to be educated about the agile method of doing business. These same people claim that lawyers perceive many agile practitioners as unrealistic and naive.

In my view, this so-called tension is the result of a misconception of the lawyer’s role and of his or her duty to the client.

Contracts and Agile Development

1. The Role of the Lawyer
2. Implementing the Parties’ Intentions through Form Contracts
3. Similarities in Agile and Other Development Contracts
4. Agile-Dependent Provisions
5. Similarities between Agile and R&D Contracts
6. What Would an Agile Contract Look Like?

The Role of the Lawyer

The lawyer’s duty is to protect the interests of his or her client. What does that mean, exactly? To those in the “lawyer as dinosaur” camp, it means that a negotiation is perceived as a zero-sum game, with success being defined as winning the maximum number of business points and shifting as much business risk as possible onto the other party. In fairness, I have seen negotiations go that way and, at times, lawyers take a leading role in those types of adversarial negotiations.

In my experience such types of negotiations are ultimately unsuccessful because the relationship and the business objective underlying the agreement usually fail. That doesn’t do anyone any good, and it can’t be viewed as truly protecting the interest of the client.

A lawyer’s job is to assist their client in reaching their business objective. Part of that responsibility includes reducing risk to the client. The definition of risk, however, cannot be compartmentalized into individual business points or contract provisions, and must include the overall goal of the contract.

In the end, the object of the contract is to document the intentions of the parties and to create a mechanism to implement those intentions.

Implementing the Parties’ Intentions through Form Contracts

Much has been written about the need for new and specialized modalities surrounding contracts intended to implement agile methodologies. For example, in 2008 the Norwegian University of Science and Technology conducted a detailed study of problems associated with contracts in agile development projects. This ultimately led the Norwegian Computer Society to adopt a standard form contract to be used for agile software development, maintenance, and service operations.  There are many other form contracts purporting to be agile friendly. For example, see the Draft/Contract for use in DSDM Projects (DSDM refers to dynamic systems development method, an agile methodology).

Although these form contracts can be useful, there are already existing procurement methodologies that can accommodate the iterative approach used in agile software development.

Similarities in Agile and Other Development Contracts

One reason existing form contracts can be used for agile is because agile development shares many of the same needs of other types of development. For starters, you need to identify the parties to the contract. You need to have an effective date and a start date. You need to state when and how the vendor will be paid.

In addition, as with other software contracts, there must be warranties from the vendor, such as one warranting that it owns the rights to the code it will be developing and selling to the purchaser. There should also be some software escrow provision allowing the purchaser to gain access to the code should the vendor file for bankruptcy or go out of business. These are just a couple of examples. There are many others.

Agile-Dependent Provisions

The tricky issue with contracts and agile development stems from the iterative process and the intentional lack of documentation regarding the scope of work or the performance characteristics of the product being purchased.

In a traditional procurement, there is normally a detailed specification or statement of work that sets the standard against which vendor performance will be measured and allows for a firm price. This approach won’t generally work in agile development. But there are other contract methodologies, such as those used in research and development (R&D), designed to deal with situations where detailed specifications are impossible. Such contracts may be adapted to fit into the iterative approach called for by agile.

Similarities between Agile and R&D Contracts

In many agile agreements the requirements, by design, are not well documented. The same can be said for R&D contracts. Parties often enter into R&D contracts without knowing whether the object of the agreement is even doable. One area where these contracts may differ is in the iterative methodology used in agile; however, this is not critical, and the iterative methodology can be documented.

What Would an Agile Contract Look Like?

As far as scope is concerned, both an agile and R&D contract would probably have a simple statement, not necessarily of work, but of goals. There would be provisions allowing for a re-scoping after every iteration, a process for identifying what was done and what was not done. With respect to those items that were not done, the contract would also document a decision process governing whether those pieces of work would be put into the next iteration, mothballed, or discarded. There would probably also be provisions for the re-scoping of work for the next iteration.

Payment would most likely be either on a cost-plus basis (with a fee or profit component) or for time and materials. Given the uncertainties of the project, a firm fixed price would most likely be impossible, but there could be a budget target or cost estimate that might go in at the front end, against which the project progress could be measured.

In this respect, an agile project would differ from R&D in that the end of the project would be defined as when the purchaser runs out of money, not when the goals of the project have been reached. Honestly, this would most likely be extremely dissatisfying to a purchaser, especially one that did not have a business history with the vendor.

There would also need to be provisions governing testing and acceptance, at the end of each iteration and at project completion. One issue is the criteria governing acceptance. If requirements are not defined up front, how do you determine what success looks like at the end? It could be defined by requirements set forth at the beginning of each iteration; the contract would require each successive set of requirements to be met for the project to be deemed successful. With this approach, one concern is the situation where all the pieces work, but the final product is unsatisfactory. In my view this is the largest problem with agile contracts, but in many respects it’s no different than an R&D contract where the parties have goals but no real knowledge of whether those goals can be achieved.

As long as the parties’ expectations regarding the final product are understood and documented up front, with the understanding that if the purchaser’s expectations are not achieved, the purchaser would only have limited recourse, then an agile-based contract would work.

Boilerplate provisions would be similar to those found in other contracts. IP warranties and indemnifications would be the same, as would severability, governing law, notifications, modification, confidentiality, and competition.

RMC is Here to Get You Started

In looking at agile contracts, the documentation requirements are not all that unique and can be fit into other more traditional procurement methodologies. There is no need to completely reinvent the wheel. Rather, the lawyer and practitioner need to keep in mind that they are creating an agreement in an environment of uncertainty, not unlike that found in an R&D contract.

In response to the growing relevance of Agile methodology for all Project Managers, the Project Management Institute (PMI^®) has begun offering the Agile Certified Practitioner (PMI-ACP^®) certification exam. RMC Project Management offers comprehensive exam preparation products, eLearning and classroom training options to help you earn PMI-ACP certification