[Followups set to comp.software.extreme-programming. Those with news servers
lacking that group should use http://www.veryComputer.com/ ]
> I just finished reading some chapters from Kent Beck's "Extreme
> Programming Explained". Wonderful book. Wish I had read it earlier.
> I have one doubt though. XP promotes continuous feedback mechanism,
> client interaction to see if things are in the right direction, etc.
> This will work fine where the contract with the customer is on hourly
> billing rates basis. What about f fixed value contrats? How do I
> quote to a cusotmer if I don't know up front what *exactly* the specs
> are and they are going to change based on continuous feedback from the
Sometimes they actually have immobile requirements, and a real deadline,
such as an airport opening.
Most of the time, though, they are only familiar with programmers who take
their money, give them long blackouts, and then deliver crap. They have
learned they must enforce a fixed price and fixed scope contract, to force
these programmers to work overtime to fix all their bugs.
The odds of being stuck with *at the end of a project are low if you
test relentlessly, don't give them long blackouts, and have your work
Tell them this, "Let's start the project with one small contract, such as a
month's time & materials. But you give us your best domain expert, during
that time, to make absolutely certain we are doing the right thing during
that month. Then, every week, we'l give you a fully working product - even
if its very small - with your most important feature in it."
Your quality, and responsiveness to steering, will inspire them to either
change their contracting habits, or they will continue to give you little
one-month contracts with a fixed scope they know you can exceed. Which is
the same difference.
(A typical XP iteration is 2 weeks, but I suggested 1 week iterations
because when a team is in trouble - such as when they have a fretful
customer - they must become >more< extreme, not less.)