Contracts for Agile Delivery

I was thinking about the contractual basis for Agile bids and came across this on our internal site. It was posted by our chief architect, who highlights this as a particularly difficult area for IT contracts. I thought it deserved a wider audience. --- Estafet Chief Architect Internal Blog Yesterday I was at an IDC Enterprise Architects Conference at which one of the presentations was on the subject of IT contracts.  It was a fascinating presentation covering a lot of ground, but one point that stood out to me was that "agile development" was highlighted as a particularly difficult area for IT contracts. Contracts for agile development should therefore focus on ensuring that the methodology is followed, and then leave that methodology to ensure value for money is achieved.   Having mulled it over for a while, I see no fundamental reason why this this should be the case.  I suspect the perceived problem is that the people creating the contracts are used to defining required functionality in the contract, and agile development doesn't really support this.  But that definition of requirements isn't necessary for the contract, its just the way it has traditionally been done. The part of the contract in question is needed to ensure that the customer gets value for money.  The traditional way of doing this is do define "value for money" up-front; I will get X for £Y, and I am happy that  represents good value. However, the whole philosophy of agile development is about maximising value for money.  Agile methodologies embody this philosophy.  Value should be delivered every iteration (sprint), through a team working on the most valuable features. The contract should clearly state the methodology that is to be followed, the team size & composition, productivity and quality reporting requirements (both active and passive), the measures that will be taken when that reporting highlights issues, etc.   Contracts should also be defined in terms of the methodology: how many sprints are included, and how long are they?  After an initial startup period, a rolling contract can be useful, though there obviously needs to be a termination clause which should allow the team to "wrap up" the work they are doing.   An agile delivery contract framed in this way will allow a team (or teams) to keep delivering value for as long as they justify their cost, and once the team no longer does so, provides a simple exit.  Really effective teams will be around for a long time; teams that follow the process but aren't particularly effective (for whatever reason) will naturally be released fairly soon, but will still have provided value.  Teams that don't follow the process may not be providing any value, but will be in breach of contract anyway, and can be dealt with easily. In essence then, agile delivery contracts should focus much less on what the work will produce, and much more on how the work will be done.  The contract and methodology will support each other, rather than conflict, and allow good teams to concentrate on what agile teams do best: creating value for the customer. --- So, what do you think? Drop me a line below (or email me) with your thoughts. Perhaps you might also consider registering for our round table event on Agile next month.