Folks seem to have the most trouble with running a fixed price contract extreme. How can you do a fixed price/fixed date/fixed scope contract if you play the Planning Game? You will end up with a fixed price/fixed date/roughly variable scope contract.

Every project I've worked on that had fixed price and scope ended with both parties saying, "The requirements weren't clear." And the typical fixed price and scope project pulls the two parties in exactly opposite directions. The supplier wants to do as little as possible and the customer wants to demand as much as possible. Within this tension, both parties want a successful project, so they back off of their primary goals, but the tension is always there.

Within XP, the relationship changes in a subtle but important way. The initial scope is a "for instance." "For example, for 5,000,000 deutsche marks we think we could produce the following stories in 12 months." The customer has to decide if those stories would be worth 5,000,000 DM. If those initial stories are what the team ends up producing, great. Chances are that the customer will replace some of the stories with even more valuable ones. Nobody complains if they get something more valuable. Everybody complains if they get what they asked for but it isn't what they now know that they want.

Instead of fixed price/date/scope, the XP team offers something more like a subscription. The team will work at top speed for the customer for a certain amount of time. They will track the customer's learning. At the beginning of every iteration the customer has a formal chance to change direction, to introduce entirely new stories.

Another difference XP introduces is caused by small releases. You would never do an XP project for 18 or even 12 months without being in production. Once the team has signed up to do 12 months' worth of stories, they will play the Planning Game with the customer to determine the scope of the first release. So a 12-month contract might put the system into production after three or four months, with monthly or bimonthly releases thereafter. Incremental delivery builds in the opportunity for the customer to terminate the contract if progress is slower than initially estimated, or if business conditions make the whole project nonsense, and it gives the customer natural points to change the direction of the project.

In the typical outsourced development, the customer ends up with a pile of code that they don't know how to maintain. They have three choices.

You could do this with XP if you really wanted. The team could come live with the customer or the customer could come live with the team. They would play the Planning Game to decide what to do. When the contract was done, the team could go away and leave the customer with the code.

In a way this could be better than the typical outsourcing agreement. The customer would have the unit and functional tests to make sure that any changes they made didn't break existing functionality. The customer would have someone looking over the shoulders of the programmers so they would have some idea of what was inside the system. And the customer would be able to steer development as they went along.

Perhaps you get the idea that I'm not thrilled with outsourcing. The "big thump" delivery of outsourcing violates the incremental change principle. There is a slight twist on outsourcing that XP can deliver. What if you gradually replaced the members of the team with technical folks from the customer? I call this "insourcing."

It has many of the advantages of outsourcing. For example, it lets the supplier give the customer the benefit of detailed technical knowledge. By gradually shifting responsibility for the system, insourcing doesn't give the customer the risk that they will inherit a program they can't sustain.

Let's look at a sample insourcing arrangement provided by the supplier of a 10-person team. The contract is for 12 months. Initial development lasts three months, followed by deliveries once a month for 9 months. The customer supplies one technical person for the initial development. Thereafter, every other month the customer brings in one new person, and the supplier takes off one person. At the end of the contract, half the team are customer employees, ready to support the program and continue development, albeit at a slower pace.

Development would certainly not go as fast with all the turnover on the team as compared to an outsourcing agreement where the supplier's team remains stable. But the reduction of risk may be worth it.

XP supports insourcing by having the team constantly measure their speed. As team members shift around, the team as a whole is bound to go faster and slower. By constantly measuring achieved productivity, the team can adjust how much they commit to get done in the iterations of the Planning Game. As experts leave and less experienced people replace them, the team can reestimate the remaining stories.

In a time and materials contract, the XP team bills by the hour or day. The rest of the process works as described.

The problem with T&M is that it puts the goals of the supplier at odds with the goals of the customer. The supplier wants to put as many people on the project as long as possible to maximize revenue. And the supplier is tempted to have the team work overtime to get more revenue per month. The customer wants as much functionality done as possible in as short a time as possible with the fewest possible people.

A good relationship between supplier and customer can make T&M work, but the underlying tension will always exist.

An excellent way to align the interests of supplier and customer in fixed price or T&M is to provide a bonus for timely completion of the project. There is a sense in which this is a sucker bet for the XP team. The control given by the Planning Game makes it very likely that they will be able to collect.

The evil twin of the completion bonus is the late penalty. Again, the Planning Game gives the XP team an advantage when agreeing to a late penalty. The team can be quite sure that they will complete the system on time, so they are unlikely to have to pay.

One feature of both completion bonuses and penalty clauses to watch for when used with XP is that the Planning Game inevitably results in changes in the scope of the project. A customer who was really out to screw the supplier could conceivably say, "It's April first and you haven't done all the stories in the original contract. No bonus, and you'd better start paying." And they could say this even if the system was successfully in production.

In general, this won't be a problem. If it's Christmas and there are presents under the tree, the customer is unlikely to count to see if they are exactly the presents on the original letter to Santa, especially if the customer has made the substitutions themselves.

If you are afraid of a customer sticking to the letter of the original stories to avoid paying a bonus, don't sign up for one. I would be wary of signing any kind of contract with that kind of customer.

One of the features of XP is that the customer can see exactly what they are getting as they go along. What if they discover halfway through that the whole project no longer makes sense? It is worth money to the customer to be able to pull the plug early. Consider adding a clause that lets the customer stop the project and pay a pro-rata share of the total cost, perhaps with an additional payment to compensate the supplier for having to find a new contract on short notice.

How could you use XP to develop a framework? If one of the rules is that you delete any functionality that isn't currently in use, wouldn't you end up deleting the whole framework?

XP is not big on "up-front reuse." In an XP project you would never spend six months creating frameworks, and then start using them. Nor would you separate the "framework team" from the "application team." In XP we build applications. If, after a few years of constant refinement, some of the abstractions start looking generally useful, that's the time to begin thinking about how to make them more widely available.

If the purpose of the project was developing a framework for external use, you could still use XP. In the Planning Game, Business would be played by a programmer who had actually built the kind of applications the framework was supposed to support. Features of the framework would turn into stories.

Once the framework was deployed outside the team, you would have to take a more conservative approach to refactorings that changed visible interfaces. Deprecation, where you give customers a certain amount of warning of the impending demise of a feature, lets you continue evolving the interface of the framework at the cost of keeping two interfaces alive for a while.

You can also use XP for shrinkwrap software. The role of Business in the Planning Game is played by the marketing department. They are the ones who identify what stories the market wants, how much of each story is needed, and what order the stories should be implemented.

Hiring an expert user of the software to be part of Business is also a possibility. For example, game companies hire expert game players to play test their software. Financial trading software companies hire traders. If you were building a typesetting program, you would be crazy not to have an expert typesetter as part of the team. And that would be exactly the person you would want deciding whether story A or story B should be deferred to the next release.