How can you leverage XP practices in a fixed-price contract? One approach is to fix the price and the schedule, but somewhat vary the scope. You reduce risk by fixing the cost and schedule. Flexing the scope means that you can respond to the customer’s changing needs as you deliver value. You can think of this as the customer subscribing to your development team’s service for a period of time. In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes about how to deal with fixed price contracts in XP.
Key Take Aways
Here’s my key take aways:
- Fix price, flex scope. Fix the schedule and price, but flex the scope.
- Reduce risk by fixing schedule and cost. Compartmentalize and constrain the risk by setting maximums for the schedule and the budget.
- Flex scope to flow value and respond to the customer. Flex the scope so you can continuously deliver whatever the customer decides is more valuable as the project progresses.
- Deliver incremental value. Find a way to chunk and deliver incremental value versus big bang.
- Think of it like a subscription. Think of it like a subscription where the customer subscribes to your development services.
In practice, I’ve found fixing the time and cost, but flexing the scope to be the most effective way to manage projects across a variety of scenarios. While there’s exceptions, the worst scenario I hit is fixed time and fixed scope where the assumption is you can buy your way to a faster solution. It reminds me of the saying, no matter how many people are involved, it still takes nine months to make a baby.
Fixed Price / Fixed Date / Roughly Variable Scope
Beck writes:
Folks seem to have the most trouble 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.
The Requirements Weren’t Clear
Beck writes:
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 customers 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.
Nobody Complains If They Get Something More Valuable
Beck writes:
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.
It’s More Like a Subscription
Beck writes:
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.
Small Releases
Beck writes:
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 month’s 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.