Part 1 of this series  discussed the inherent challenges of contracting for software development using a methodology known as agile software development (ASD). Some ASD proponents openly question the need for contracts altogether, but principles must meet reality in the business world. Accordingly, Part 2 of this series examines ways to leverage ASD to your benefit while managing its risks in a practical contractual framework.

Because ASD emphasizes a fluid, collaborative approach to software development, it’s helpful to think of an ASD contract as a form of strategic alliance between the contracting parties. In a strategic alliance contract, the parties must carefully consider the appropriate allocation of rights, responsibilities and risks because the natural delineation between the parties is not as clear-cut as it is in a more traditional services arrangement. As a result, there is greater emphasis on risk-sharing and issue resolution, and less on specific remedies and liability than in the traditional model.

ASD forces us to discard our assumptions about “standard” terms for software development in several areas, such as the following:

  • Business Requirements/Specifications – Rather than attempting to define every detail of the solution to be built in the contract, set out a list of agreed upon business objectives for the project, then proceed to a phase of “blueprinting” using ASD methodology to hone those objectives into more concrete specifications.
  • Milestones – It will be important for the parties to agree to development milestones in the contract. ASD advocates say ASD works best when a big project is developed and tested in discrete pieces, which provides frequent feedback and problem resolution. These pieces are not intended to carry contractual remedies such as liquidated damages or termination rights, nor are they are intended to have static deadlines (see discussion of change management below). It may be more helpful to identify the escalation and resolution process to follow at each milestone if the timeline is slipping, as well as “off-ramps” where the customer can exit the contract.
  • Ownership and Licenses– Different types of intellectual property have different rules for ownership of jointly developed IP, and these rules also differ by jurisdiction. It is essential that a contract for ASD clearly specify which party owns new IP and whether any licenses will be granted to both new IP and pre-existing IP. At the very least, in a joint development setting, each party will need a license to the other’s pre-existing IP in order to collaborate. But do not assume that common law or statutory rules will provide clear guidance on ownership rights in the absence of ownership allocation provisions in the contract.
  • Change Management – A principal tenet of ASD is to assume (or even welcome) constant changes in scope as a natural progression of the creative process. As a result, traditional concepts of change orders and pricing adjustments will only weigh down the process and will likely result in significant cost overruns. Change proposals need to be considered and resolved quickly, and should be as malleable as the original scope. It will be critical to build frequent testing into the process to ensure the scope evolves to meet business objectives (and does not veer off into oblivion). But changes in scope should not result in frequent price adjustments. The pricing model for an ASD project should assume scope creep, constant customer intervention and continual governance without ratcheting up the cost of the project.
  • Liability – The least pleasant topic for developers is likely going to be how to allocate liability in the contract, particularly where collaboration and teamwork are so highly valued. The key point here is that ASD requires a sharing of responsibility, and therefore a sharing of risk, in ways that don’t necessarily fit with a traditional customer-vendor relationship. IP infringement risk, for example, becomes complicated when both parties have contributed to the conception and development of the software. It may be appropriate to put a cap on each party’s liability for infringement claims because it doesn’t make sense for either party to bear the full risk of claims against the other, or it may make sense to remain silent on the issue altogether. Start from first principles. There may not be a precedent agreement you can rely on for guidance here.

These are just some of the issues that are likely to come up in a contract for development based on ASD. While they are manageable if both parties are willing to be open and creative in the contract negotiation, they will require a commitment of time and resources to get the contract right. The right service provider should be willing to make this investment as part of a longer-term strategy in securing your company’s business.