Hi all,

Hope you don't mind my sharing my xp success story (and a plug if you
read the whole thing)

My company went live yesterday and what a fine ride this was. I've
been doing some form of XP since I bumped into XP Explained 1.0,
sometime around '99. I knew it was possible to have your cake, eat it,
and still have time left for eating more cakes. Many stars aligned
properly during the past 6 months to make it possible. Something that
was not happening before.

In my previous projects, my teams using XP (or a dumbed down version
of it) were still being more successful than other teams using
everything-but-XP. Still, I knew that having 17% less bugs or less
people quitting was good but not great.

So what did we do this time that made the difference?

- People:
We formed a team of people who *wanted* to work in a agile
environment. For those who recently discovered XP/agile and are
excited by it, let me tell you, not everyone is! It can be a pain,
okay, it *is* a pain having to convince people that tests are good,
yagni is good, 6 month iterations are not short, simply removing all
comments from your code is not refactoring, etc, etc. So not
surprisingly, #1 key to be successful with any process you choose, is
to get people who are motivated about the said process. When
interviewing, make sure to pair program, request tests first, call
yagni. They might not know how to do it right (TDD is hard at first)
but if at least they seem interested it's worth considering them.

Don't think you can shove your process down people's throats. You can't.

- Customer:
In *my* experience one of the flaws with agile in general had been
that Customers (or product managers) suck (well, they do!).

It's not unusual to get stories like "I need a rules engine" or worse:
"I need something compelling, how many days for that?".

This time was way different. When devs and prod manager first got
together, she (the PM) had a stack of index cards that I could
estimate for the most part at 1 or 2 points. Where 1 point was an
ideal eng day. Nothing was ever estimated at 3 points or more. If
something was bigger than 2 we would break it down into smaller
stories.

Truly amazing. After 6 months I'm still shocked but how good she is.
Oh, she had no experience with agile before but she was a waterfall
victim. It helped that she clearly understood what she needed. Good
"customers" have my seal of approval.

So between a customer who knows what s/he wants, and one who can' be
bothered talking to devs, pick the former.

- Technology:
Given that the team had 25+ years of combined experience with Java and
J2EE we considered using the big J...for about 5 minutes. All of us
wanted to try this Rails thing that people keep talking about, so we
went for it. What a fine decision that was. Not only Ruby is a great
language, Rails itself makes it really easy to do things right. I had
never had more than 50% code coverage in my previous web apps, but
here we consistently over around 97%. Not only it's a nice number to
regurgitate, it does have its practical advantages. We can truly be
agile and embrace change. Just add tests, code the feature, run all
tests, done. No surprises. Well, no silver bullet yet, so there will
always be surprises. But to the purpose of this exercise, I would say
that reducing the surprise factor by a factor of 10 qualifies as "no
surprises".

This doesn't mean you have to use Rails. Java/.net/whatever are just
fine I'm sure, but if you can't get close to 100% coverage in an easy
way, you're going to have a hard time being agile. At least I had a
hard time with those.

- Short iterations:
We started with 2 week iterations, providing real, verifiable value at
the end of each one. At some point we switched to one week iterations.
Mainly because it was easy and useful.

This made a big difference in keep the whole team focused. We wound up
in a different place that we had envisioned, so short iterations were
a big help. Yay for embracing change.

So squeeze your iterations as much as it makes sense (that might be a
month, a day or a week). If it's more than a month, I would be
suspicious, but I'm sure it depends.

- Motivation:
It helps that everyone from devs to qa to business to marketing was
really excited about the mission of the company. (get ready for the
plug now).

At MicroPlace (http://www.microplace.com) we think we can help you
reduce poverty. That is obviously very exciting. It beats building
enterprise software for BigCorp where your audience are the buyers at
OtherBigCorps, not even the actual users.

So between an exciting project and a boring one, I would go with the
exciting one. I'm crazy like that.

It was surprising to me, but as it turns out if I work with a bunch of
dedicated people who are excited about what they're doing, use a
process where changes are expected, use the right technology and my
"customer" knows what she's doing, things work better.

Oh, and no nights or weekends necessary. Yay for agile! Not a silver
bullet, but it's pretty damn shining.

--
Julio