It’s very common to get involved with contracts in an Agile scenario nowadays. Agile tells us to “keep our eye on the value meter.” And, once we see that our
Risk is the major driving force behind contracts
All too often, we start writing contracts the way that we’re been taught to write contracts. Spelling everything out. What's expected. When it’s expected. How much this is all going to cost. And so on. And, very quickly, we realize that we’ve gone from a very Agile way of thinking about software lifecycle and reverted back to the dark days of Waterfall. Because all the requirements, schedule, and cost are figured out up front.
“But wait!” you tell me. “If I can protect my interests by way of a contract, then I can reduce my risk that unforeseen events will keep me from getting to my goal of set functionally on a date given for a price agreed upon.” To which I reply, “Yes. If things go wrong, you might be able to sue on the contract. And maybe even win. But is that what you want? Is that why you started the whole process?” The truth is that you really want the software being contracted for, not the damages you may (or may not) be entitled to. Most of the time, missing out on a market opportunity is far more damaging than simple damages that you may be entitled to under the contract. Yes. You can negotiate liquated damages up front in the contract, but why would a contractor sign up for loads more than the simple damages that would normally result in a contract non-performance failure?
Continuing along this line of thought, we quickly arrive at the point where we realize that risk is the major driving force behind a price stipulated in a contract. The truth is that we actually raise risk in traditional contracts while living in the fantasy land of “safety by contract terms.” We work under hidden risks of:
- Inflexibility to respond to changing needs. Taking delivery of something that is on-time, on-budget, and on-feature that we asked for a year ago – but is no longer desired – is the illustration in the dictionary under “epic failure.”
- The tendency on the part of both parties to not bother with monitoring progress or taking interim delivery of feature snapshots is heightened, because “we’re just wasting valuable time and money on monitoring and/or integrating things that were previously planned.”
If I know that there is flexibility in being able to collect under a contract, I can charge less for my work than if the penalties force me to “carry performance insurance” to meet potential contract liabilities. And who pays for that risk? Ultimately, it will have to be borne by the purchaser of the goods or services.
Writing a contract with agility in mind
So, what’s so different about a contract that is written with agility in mind?
- We acknowledge that change in requirements is inevitable and expected.
- We acknowledge that estimates are imperfect, and are never the “exactimates” that we want to specify when computing a contract cost.
Unhappily, transforming the traditional fixed deliverables/fixed length/fixed cost contract into an Agile contract is not as simple as adding in those two bullet points above. Remember this. Agile contracts try to minimize costs and maximize benefits due to the inherent risk sharing aspect when examined next to traditional contracts. You can contrast the differences between conventional contracts and Agile contracts it this way:
- Conventional contracts
- Companies inevitably look out for their own interests
- Contracts are needed to limit opportunistic behavior
- Agile contracts
- Assume the other party will act in good faith
- Form a relational contract - let the relationship limit opportunism
- Align the best interests of each party with the best interests of the de facto “joint venture” between the parties - use the contract to set up incentives
So, what are the various ways for software goods and service providers, and their customers to engage with one another? Here’s a sampling of some ideas for contracts:
- The traditional fixed price, fixed cost, and fixed scope. As I’ve been discussing, this is the contracts style of Waterfall development, with the added “bonus” that you may be on-time, on-budget and on-feature but deliver a project that is useless to the customer because the contracted requirements were wrong.
- Traditional fixed price, fixed cost and fixed scope, with the duty to collaborate. The danger here lies in the potential to not have collaborated properly.
- Time and materials. This is not really a contract with any deliverable specified, so the danger here lies in not completing the work intended in a timely or cost effective manner.
- Not-to-exceed with a fixed-fee clause. This is a variation on a time and materials contract where the requirements are “known” up front, but the time and cost are not readily apparent. Fixed fee refers to the profit margin for the vendor. Typically, a target date is set and there are both incentives for early performance as well as penalties for exceeding schedule.
- Price per story point. Some vendors attempt to embrace Scrum practices at a deep level and directly apply story points to the contracting process. The vendor decides on the number of points for a story, and the customer decides on which stories to do when, paying only for the points meeting the story’s acceptance criteria. Issues that arise deal with the estimation process. Which estimates are used (epic versus detailed, and how detailed)? Who pays for the estimation? How does the velocity calibration phase work [what, when, and how much]? Who arbitrates on when a story is “done” but not “accepted”?
- Incentivized price per point. Using the price per point model, estimate duration using velocity and pay a smaller amount for work completed earlier than originally estimated, but at a higher per hour rate (and perhaps a smaller amount per hour for work completed late). This usually has the same issues as price per point contract, but it encourages getting the work done faster in the same fashion as the not-to-exceed with fixed-fee model does.
- Incremental delivery. This is actually a feature of just about all contract forms that meters the payments based on predefined performance goals with an option to cancel should the milestones not meet expectations. But the expectation is that the milestones will be met on-time/on-feature/on-budget. So, how is that very different than traditional contracts?
- Incremental acceptance. Again, this is a feature of just about all fixed requirement contracts that withhold payment at a contract milestone if the predefined acceptance criteria are not met. This is usually an attempt to ensure that up-front requirements errors do not result in contract fulfillment without useful work product being produced. But how does the acceptance criteria section work if the requirements are not reliable from the start?
- Target cost. Here, we define an initial target of functionality, contract for initial estimates of time and cost, build in contingency buffers for incentivizing early delivery yet guarantee that later delivery still has business viability, and accept scope change within the contingency buffer parameters. This is actually pretty close to ideal. But large changes, those that are outside the contingency, will require renegotiation. That can be sticky to deal with if the parties are not in a meaningful relationship.
- Joint ventures. Here, two companies completely share profits and risks. This is probably the most Agile of all contract arrangements, but this is not without its own disadvantages, either. For example, what do we do with such issues as intellectual property, Sarbanes-Oxley, loss of interest by one side or the other, etc.?
Want to know something? I think they nailed it in the Agile Manifesto. “Collaboration over contract negotiation.” We just have to be creative in coming up with the implementation where both sides partake in the benefits of the relationship, come what may.
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.
This was first published in May 2012