On Mon, 2008-01-14 at 09:42 +0800, elan J wrote:

> Hmm makes me wonder.. does XP works on a fixed cost project ?

It depends on what you mean by "work". If you mean, will it help you get
the most value for the money spent, yes. If you mean, will it let you
know as early as possible if you're not gonna meet all of the goals (if
that's the case), again, yes.

If you mean, will it cause the impossible to suddenly become possible,
no (well, unless it was only very slightly impossible :-). If you mean,
will it enable you to delude yourself into thinking you can do too much
work in too little time, again, no.

If you mean, will it give you a magic wand, to make the people who want
more done than time and resources allow stop being unreasonable...
maybe. It depends on whether they're prepared to face reality, and even
more importantly, on _how_ they're prepared to face it. Further
exposition below.

> In a fixed cost project, PM want to do the project on time and on budget, so
> PM tends to give pressure to us developers to finish things quickly.
> Not to mention the customer who want changes here and there also, makes us
> want to scream out to the PM, we need more time. This puts the PM in a
> dilemma because he need it to finish on time and on budget since it is a
> fixed cost project, but at the same time the software need to accomodate the
> business values. A real headache for us developers, cause the pressure comes
> from both ways, the boss and the customer.
>

Yep. Welcome to every fixed price contract I've ever heard of. A news
flash, though: most of the time, the people applying the pressure
_already_ _know_ they aren't going to get everything they ask for. They
just don't know any other way to get as much as possible. The logic is
simple (albeit incomplete and incorrect): the harder they push, the
harder the programmers will work, and the more will get done.

I had a paragraph here detailing the bad things about all this, but we
all know them, so I deleted it.

Fixed price, fixed scope contracts are a stupid (but common) way to do
business for software development. They're popular because financial
people are comfortable with them, but no one really develops software
that way; it's just that instead of building the unknowns into the the
contract (ala optional scope contracts;
http://www.jarn.com/about/OptionalScopeContracts.pdf), many
organizations prefer to get more or less the same effect via ad-hoc
methods involving lots of posturing, raised blood pressures, and
"contract amendments", "follow on contracts", etc.

Even if you can't get the nirvana of a sane contract structure, XP lets
you deliver something they'll be much happier with. It still won't be
everything they want (it seems to be a law of nature that fixed price
contracts always have excessive scope), but it'll be a subset they're
much happier with. Many times, they'll decide the subset is enough; if
it isn't, then they've got a software partner they can trust, so the
"maintenence contract" or "supplemental work contract" or "contract
extension" or whatever will go smoother and happier for everyone.

But _your_ side of that is that you have to be honest enough to tell the
truth, even when it's not what the person you're talking to wants to
hear. Not whine about the truth, but accurately, calmly, and
professionally report your progress, how much the customer can expect to
get from you every time you sit down to plan an iteration, etc.

There are good reasons why the white book talks about "courage". It's
not a joke or "feel good" filler, and it's not easy.

-John

--
John A. Maxwell (jmax@...)

"Security is mostly a superstition. It does not exist in nature, nor
do the children of man experience it as a whole. Avoiding danger is no
safer in the long run than outright exposure. Life is either a daring
adventure or it is nothing."
- Helen Keller