I helped institute and coach an XP project
a few years ago. Here are my
answers to Jason based on that XP experience:
1) Do
you follow XP to the letter of the law?
We tried to follow
the law as best we could. At the time we started, the only thing we had to
go by was the "White Book" and some postings on the internet. So, I'm sure
that we did some things in a less than optimal way.
Some of the
practices will break down if you don't follow the "XP Way" pretty closely.
For instance, if you don't use a war room, then you are sure to suffer
communication problems. XP isn't big on documentation, so the informal
communication you get from being in the same room is
critical.
As you have probably
read, each practice tends to make up for the shortcomings of another. If
you don't follow one of the practices then you need to do some other practice to
take its place. For example, if you don't do pair programming then you
should have formal code inspections.
While several of the
practices work well on any project, it is my opinion that if you are going to do
XP, you will be much better off if you follow it completely.
2)
What bits did you leave out?
We didn't leave
anything out, but there were practices that we didn't execute very
well. I attribute this to a lack of XP training at all levels of the
organization.
3)
What bits did you add?
The most important
thing we added was to still have a traditional QA staff. XP doesn't really
say whether you should do this or not, but I think that it is a good
idea. My reason is that XP really doesn't address integration
testing, stress testing, or usability testing very well. It also
doesn't address the fact that you usually can't develop your system in
the production environment. So, you need someone to
do production testing.
XP zealots may
disagree, but I think it also helps to have a separate QA group doing some
old-fashioned black box testing as a sanity check.
4)
What team sizes?
We stuck with teams
no larger than 12. I think that even this is too many. Just my gut
feel, but I wouldn't go past 10.
5)
What kind of projects?
This was a J2EE
web project. It was a pretty complicated application. The front
end work was done by another group that was not using XP.
6) What was the fallout
after you implemented XP? How many just wouldn’t accept the
change?
XP was well-received by most of the development
staff on my team. I found that about 5-10% of developers just couldn't
deal with pair programming. But, I think that most tend to enjoy it.
I think it is a fun and efficient way to develop good code. But, but it is
definitely not for everyone or for every kind of project.
Also,
the on-site customer caused some problems. Those tasked with generating
requirements really never got on board, and that was a source of friction.
You have to choose a customer (or customer proxy) that is willing to dive in and
work with you in a more informal way. If you can't find this type of
customer then you are probably better off either modifying your version of XP or
just using some other methodology. I haven't kept completely up to date
with the literature, but I have heard there has been quite a bit of
rethinking in this area. So, a more modern XP approach may have a better
solution to the on-site customer problem.
7) Did
you have any issues maintaining the XP discipline?
All of
the developers acquired some degree of XP discipline, but we could have
done much better from the start if we had more training. Some of them
spent a lot of time getting good at skills like refactoring and test-driven
development. I think most everyone tried to do XP well, so from that
standpoint discipline was high.
8) What was the general
feeling from the team? Which aspect of XP had the most controversy with your
team?
Except for the one or two developers that couldn't
accept pair programming, I wouldn't call any aspects controversial. Any
controversy really came from outside the team. It is really important let
the entire organization know what you are doing and why you are doing it.
This can be tough because it is so different from what everyone is used
to.
Conclusion
A
few months ago, I visited the same XP lab that Jason went to. I was also
duly impressed. This was a very large XP shop with several XP teams.
As far as I could tell, XP was working very well with very impressive quality
numbers. This lab was a level above the one I worked in. It was very
well funded.
What Jason saw last week concerning high energy
and camaraderie is confirmed by my experience a few years ago. You
work VERY closely (literally!) with other team members, which does raise
the level of camaraderie.
You are very tired at the end of the day, because
it is 8 hours of non-stop thinking and coding. Energy level is
tremendous.
Overall, I'd recommend XP for other
projects. It does work!!! However, proceed with some caution.
Because it is different from the norm, people will
tend to blame any shortcomings of the project on XP. So, it is important
to educate the whole organization on XP. Then, as the project progresses,
make sure you continue to publish your results and be as transparent as
possible.
Also, I can't stress enough how important it is to
properly train the development staff. At first glance, the practices sound
easy to implement. However, it actually requires skills that most
developers simply don't have (even though they often think they do). Few
have ever done formal pair programming. Few have
mastered refactoring to the point that it is part of their day-to-day
work. Very few actually have done test-driven
development. These skills and more are required to execute XP well.
It is better to train them at the start then to watch them struggle for several
months.
Stan
Silvert