Working Group Formed to Produce Reusable Agile Contracts

Posted by Vikas Hazrati on Oct 29, 2008

Sections

Process & Practices

Topics

Collaboration ,

Agile ,

Agile in the Enterprise

Tags

Contracts & Negotiation

Contracts are required to bridge the gap of trust and uncertainty between different organizations thus enabling them to work together. Traditional ‘fixed price, fixed scope and fixed time’ projects do not take the uncertainty in business environment and software development into account. These contracts tend to set up the customer and vendor against each other where, instead of collaboration, time and energy is spent on deciding who should pay for the change. A working group is currently brainstorming on OpenPlans with an aim to produce reusable agile contracts. This would potentially reverse the customer-vendor relationship from confrontation to collaboration.

In the past Alistair Cockburn has listed more than 10 strategies of Agile contracts based on inputs from several people. These include the standard ‘fixed price fixed scope’, ‘time and material’ contracts to the more innovative ones like ‘Incremental delivery with payment on incremental acceptance’ and ‘Indefinite Delivery, Indefinite Quantity’. Martin Fowler talked about projects where they first build trust with the customer and then get to a flexible charging scheme for future projects. Mary and Tom Poppendieck have discussed various contract types and their potential benefits. They also discussed various customer and vendor categories and the factors like culture, country and software type which might affect the contract.

The working group on OpenPlans currently has a work in progress Agile contract titled ‘Money For Nothing, Change For Free’ which places strong emphasis on customer participation. The customer is expected to have a high degree of involvement in prioritizing features, sprint planning, writing conditions for satisfaction of features and sprint review. The contract also has the following clauses set up

• Early Termination (Money for Nothing)- Customer can terminate the contract at the end of any sprint by paying 20% of the remaining contract value
• Change For Free – Customer can add new features at sprint boundaries if items of equal scope are removed from the contract.

The contract also talks about ‘Guarantee of work’ where the vendor guarantees that 80% of the functionality is delivered with high quality as per the agreed upon definition of done and that the vendor may take the risk of late delivery.

The contract development can be tracked on the ‘Agile Contracts’ home page and membership can be requested for contributing to the contract definition.

1. Back to top

   It is hard to make and sell an Agile Contract

   by Vikas Hazrati

   In my personal experience I have seen that it is hard to sell an Agile contract. Some of the initial analysis of the working group shows that it is more of a function of sharing risk. There is a suggestion of a 2 phased approach where the balance of risk shifts.
   
   Still most of the enterprises that I have seen prefer a fixed kind contract to satisfy CYA. Has someone successfully executed/executing a real not pseudo ;) Agile contract?

   Reply

2. Back to top

   Re: It is hard to make and sell an Agile Contract

   by Jeff Sutherland

   Working with Exigen Services, a large Russian consulting firm, we have done CIO dinners in New York and London and found that 1/3 of the CIOs were ready to negotiate a "Money for Nothing, Change for Free" contract immediately. Another third wanted sales visit to discuss the approach in more detail. The final third said their companies were too disfunctional to produce a product backlog prioritized by business value or were so bureaucratic it was impossible to innovate.
   
   The conclusion was that there is a huge immediate market for this and Exigen Services has made this a core strategic initiative worldwide.
   
   In their initial projects, the challenges have been training their own people to be Scrum Product Owners so that they can work with the customer as stakeholder and get a good Product Backlog. The customer cannot in most cases produce a good backlog on their own. The second difficulty is the estimation capability of their development teams. They need to be good at estimating fix priced contracts where there is limited information on large grained stories. Systematic Software Engineering, a CMMI Level 5 company in Denmark is doing this quite well so we know this is a solvable problem.
   
   So the bottom line is that we need Agile companies that can execute well in this market. As soon as we have them there are huge financial returns for both the vendor and the customer. The customers are already ready.

   Reply

• Older >