Many organizations that perform enterprise-driven software development—developing software for use inside their organizations—often hire outside firms to supplement their internal software development capabilities. This is especially the case when the organization does not have expertise in a given technology or application type—think customer relationship management or content management, for example.
This poses some interesting challenges for organizations that are implementing agile methodologies because they have to consider how to work with vendors and integrate them into their agile approaches, and this has a special impact on their contracting practices. I am working with an organization that is facing that challenge right now, so I thought I'd see what other people's experiences were dealing with contract relationships when trying to follow a philosophy that values customer collaboration over contract negotiation.
A good agile contract establishes the framework for collaboration to occur during the project while providing appropriate levels of protection and risk mitigation for both the customer and the supplier, without having to resort to negotiation too frequently.
In the blog post Must-Haves for Agile Contracts, Alex Adamopoulos describes the important characteristics of an agile contract. One of those key ideas is moving to an output- and outcome-focused contract, where "the contractual commitment is for the amount of the output (in the form of fully working software that is ready to be deployed) rather than the detail of the output (i.e. the actual specifications).” Outcome-based contracts can help make both parties’ objectives and requirements clear without interfering in process methodologies.
While outcome-based contracts inherently try to avoid fixing scope, many organizations find that some limits are still needed in the contract. The best way to describe the scope of a project may be by creating the backlog for the project, then establishing a total size of the backlog expressed as a certain number of story points to set the limit to scope agreed upon in the contract. This places some constraints on how big the project is but still allows for flexibility in what is included within that scope.
In addition to defining scope, the contract should establish a way to determine costs. One approach that I have used on a project with a vendor is to charge a set amount per story point. The premise with this model is that the customer is only billed for stories that are actually completed and meet agreed-upon acceptance criteria. The one thing that became immediately apparent from all these resources is that there are several ways you can approach writing contracts between two organizations working on an agile project. But to be most effective, the contract needs to create boundaries without hampering the organizations’ relationship. It’s also important for both organizations to come to an agreement about what each means when it says “agile.”
