BrainHzSoftware.com

Agile Contracts

Posted by Scott Reed on 5th May 2007

For the first time in my career I find myself writing contracts. After doing a little research about the traditional types of contracts, they seem to be inherently anti-agile, which goes against my way of thinking. After doing more research I found one type of contract which seems especially suited to my agile beliefs, but I realize that most businesses won’t understand why I write contracts this way. I am writing this blog entry in order to justify the peculiar type of contracts I write.

There are essentially two types of traditional contracts: fixed price and time and materials (also called labor and materials). Let me discuss these one at a time.

Fixed price contracts are where the product and the payment are agreed-upon before starting the project, and the compensation is paid regardless of the actual costs.

Fixed price contracts are risky for both parties. The business can end up paying way more than they should, and the software development firm can end up not getting paid for a significant period of time. For example, if something unforeseen goes wrong, the software developers could be working for months at the end of the project with no pay at all. In the other direction, the software team could convince the business that the project is going to take a long time to complete, either maliciously or unintentionally. Then, during the course of development the software engineers may find something which enables them to finish the project in a couple of weeks (e.g. open source code which does the bulk of the work) and sit on the project until the due date. Software developers have to pad or buffer the estimate to protect themselves against unforeseen circumstances, but if nothing goes wrong the project may complete early, once again causing the business to pay more than it should have.

In addition to the risk of paying too much money, or not getting paid enough, depending on your perspective, fixed price contracts have the potential to be used against either party so that neither party gets what they want. I call this hiding behind the contract. The developers want to get paid, but businesses can insist that they meant something else by the wording in the contract, and refuse to pay until what they were thinking is achieved. On the other hand developers can delivery shoddy software which “meets the requirements”, if no mention was made in the contract of quality, maintainability, stability, etc.

From a business point of view fixed price contracts are also difficult to manage. In fact they are more like gambling than management. In real life managers would never give their teams a contract and tell them to go build the software without allowing for frequent reviews to gauge progress and make adjustments. So if businesses wouldn’t act this way for their own teams why would they allow teams outside of their organization to act this way?

Fixed price implies one more thing which is bad for businesses: fixed goal. Often during the course of creating software, during a review for example, there is a flash of insight on the part of the business, and a resulting decision to move the product in a slightly different direction than originally specified. This direction is often more marketable, more user friendly, or simply meets the needs in a way that the originally specified product couldn’t. But if it takes more time to implement then obviously the developers are going to have a problem with spending more time for the same amount of money. Similarly on the software side, once some parts of the software are completed it can shed light onto other parts of the software, and result in drastic changes to the estimates. Instead in order to obtain a good software estimate, a lot of energy needs to be expended up front that can not be billed. This effort doesn’t result in any work towards the actual software, again a loss for both parties.

Hopefully I have convinced you that fixed priced contracts have a lot of drawbacks.

The second major type of contract is a time and materials type of contract. This type of contract basically states that the business will pay the software developers for the amount of work that they do until the project is completed. Time and materials contracts are only dangerous for the business, because the software developers are guaranteed to get paid for the amount of work they are doing even if it isn’t furthering the project in any way. However, a lot of businesses won’t accept time and materials contracts, for this very reason. Ultimately software development companies who restrict themselves to writing these contracts may lose a lot of business.

As I was contemplating this I remembered reading in Agile Software Development Ecosystems by Jim Highsmith, about another type of contract that fits into the agile philosophy a little better. In the world of rapidly changing requirements, the type of contract that makes the most sense is an iterative one, where each iteration gives the business a chance to give feedback to make the product better, and choose which features to implement next. The problems with the fixed price contract are that they are unchangeable and don’t require or allow for this sort of frequent contract revision with the customer. The problem with time and materials contracts is that they don’t tie the work software developers are doing to particular features in the product or hold them accountable for getting “real” work done.

Highsmith mentions a fixed schedule variable scope contract called a delivered feature contract. This style of contract states as long as there is work to be done, and the business is happy with the work delivered the project continues. There are two important points to this type of contract. The first is that there must be periodic reviews setup, to make sure that the software developers are making the business happy. The second is that there needs to be a prioritized list of features that the business needs developed which is the work to be done. If initially the business thinks that it requires a huge number of features, but as the project progresses they realize that they can ship with a smaller subset, the project will be over as soon as the subset is delivered. At the periodic reviews the company can critique the software delivered thus far, potentially correcting issues early on that would have huge ramifications later in the project. They also get to decide together what to work on next, so that if the business has an idea to change the product after the contract has been signed it can be done.

Delivered feature contracts also protect the software developer by paying for the work done on a feature, not a fixed price per feature. With that said, the most obvious question is how does the business know how to budget for a delivered feature contract, since there is no fixed price? In other words how does it protect the business against the problems of the time and materials contract? If written correctly estimates can be included so that they have some idea of how much money the project will cost. In addition the project can be terminated after any iteration, allowing the company who chose the wrong software development firm to get out early.

This blog entry draws upon the works and talks of many members of the agile movement including but not limited to Jim Highsmith, Robert Martin, Kent Beck and Scott Ambler.

Tags: ,
Posted in Agile | Comments Off