Extreme Contract

In order to be useful in an outsourcing project, a software development methodology must work smoothly together with a business contract. Since ExtremeProgramming is a different kind of methodology in some important aspects, we might need a different kind of contract. Do we need an ExtremeContract? If yes, how does such a contract differ from a ClassicContract??

How do we formulate such a contract? KentBeck and MartinFowler suggest the following in their book PlanningExtremeProgramming:

: Supplier will have eight programmers work for Customer for two months for $320,000. Scope will be negotiated every TwoWeeks according to the classic book Planning Extreme Programming

I guess we shouldn't take this too seriously. Probably the writers' intention is to provoke us to start some kind of discussion about the subject. It is time to pick up the glove. The question is:

Is there such a thing as an ExtremeContract?

In order to effective a contract must fulfill a number of criteria.

The customer must have some kind of way to compare candidate contractors. It must be possible to compare an ExtremeContract with a ClassicContract?.
If something goes wrong and the project fails, it must be possible to determine who is responsible for the failure.
More...

Have someone used ExtremeProgramming in an outsourcing project. How did you convince the customer to choose you as a supplier? -- DanielBergh

I have this feeling that it's not usually contracts the customer compares, but tenders following what's known as an invitation to tender. I'm not 100% on this, but I'm sure there must be someone here who can fill in the details or correct me. --ChrisSteinbach

Yes, of course. You are right. Maybe we are talking about an ExtremeOffer?? Anyway, it would be related to the contract (and have the same problems). --DanielBergh

You can also do some of this with a "Performance Based Contract". The contract establishes the performance-based criteria with appropriate severability clauses. Agreed-upon scopes for each itiration can be handled by 1 page contract amendments.

I'm not sure if I understand what you mean with a PerformanceBasedContract?. Can you clarify? Performance (in the sense of amount of features per time unit) is not in the customer's primary focus but rather amount of business value for the invested money (of course that could be our definition of performance as well).

I think this is a common (simplified) scenario:

The customer sees an opportunity to improve his business in some way. Common improvements are:
- Increase sale of a specific product
- Reduce effort required to deliver a product, which leads to possibility to reduce staff.
- Increase quality
In order to implement the improvements the customer needs some kind of IT-support. Since he's not capable of building that support of his own he chooses to buy a solution.
The customer writes a request for quotation and sends it to candidate suppliers. The request usually includes some kind of high level requirements and a timeframe.
When the customer receives the offers he evaluates the BusinessCase for each offer. The offer that yields the most positive BusinessCase wins (of course there will be a lot of negotiation in between...).

Clearly it isn't enough if a supplier promises to deliver functions at a specified rate, since there is no guarantee that these functions really fulfill the business needs. And it is not likely that a supplier is willing to guarantee the business value. After all the offered solution doesn't generate money by itself (if it's not a printing press). But if the supplier offers a solution (not just work) the customer can evaluate the solution.

A wise customer would at least consider the following:

Is the suppliers suggested solution realistic?
Does the supplier know what he is doing? Has he tried to do anything like the suggested solution before? If yes, is there any evidence of success (references)?
Is it likely that the suggested solution fulfills the business needs?
How can we be certain that the supplier is committed?
How much of the risk is the supplier willing to take?
How much does it cost?
When are we going to get any value from the solution?

If the supplier takes any risks with the contract (and he always does since a failure will tarnish his name), he also needs assurance that the customer is committed.

An offer could look something like the following:

We think that the following solution is what you need: (A very high level description of the solution. The description may differ from the requested requirements.) We promise that we can construct this solution in X months for Y dollars (here the supplier takes a risk) if we fail the following conditions apply (here the supplier guarantees its commitment). We don't guarantee that the technical solution is exactly the same as stated above (the customer shouldn't care anyway, and it's always good to have the freedom). During the project you will have the freedom of specifying the functionality at will. The implementation effort of the functionality you specify will be compared to the effort in the offered solution continuously, assure that you get the same amount of functionality as promised (and at least as much value).

The features of the proposed solution could be assigned values (a kind of FunctionPoints). The value of the UserStories developed during the project would also be assigned points. The exact number of points for a user story should be negotiated during the project and should roughly correspond to the number of points of a proposed feature requiring roughly the same amount of development effort. If the business value for a user story is higher than that of a proposed feature the point amount could be slightly higher (this will encourage the supplier to look for solutions with more value and encourage the customer to go for simpler solutions in case of equal value).

Special features of this process are:

The product of the project is never compared to the original requirements (even if no changes are made). This forces the customer to produce acceptance test cases (which is good since I've never seen a customer producing these timely).
If the customer doesn't specify any user stories the initially proposed features could be implemented instead. The project model will collapse into a "safe" non-extreme project.

This is a quite theoretical construction. It may have many flaws that prevent it from working in practice. But the key points are:

We have to give the customer an indication of the amount of business value since he needs to justify his investments.
The customer is not interested in what he gets, just what it's worth.

Does someone have any comments or other suggestions? --DanielBergh

FYI, I asked about Kent's OptionalScopeContracts on the extremeprogramming Yahoo group (http://groups.yahoo.com/group/extremeprogramming/message/56518). Very little came out of it - a couple of people had actually succeeded in having contracts similar to optional scope contracts.

ChanningWalton

I've read the article about OptionalScopeContracts. It doesn't deal with the problem that the customer wants a way to compare different suppliers before buying. Nor does it deal with risk sharing. Today we have the buyers market (at least where I live), and it is hard to imagine a customer accepting to risk a lot of money for just words... I do think we really need to address these issues! --DanielBergh

EditText of this page (last edited January 12, 2005)
FindPage by browsing or searching

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006