

Why Extreme Programming Fails - kfrench581
http://codewright.blogspot.com/2009/06/why-extreme-programming-fails.html

======
bena
The thing that makes me most wary about XP is its origins. They developed XP
practices while working on the Chrysler Corporation Compensation System, which
was eventually scrapped in an unfinished state after 5 years.

However, XP is touted to be a system of practices to enable people to get
software created on time and under budget that is more adaptable. The skeptic
in me just screams, "But your first big test case failed on all those
accounts. How can you recommend these practices when, in practice, they didn't
work?"

Also: The 48 Laws of Power read more like the 48 Laws of Douchebaggery.

~~~
baltoo
I was under the impression that while C3 wasn't finished when the project was
terminated it was used productively after only two years.

Also, it the project replaced one that had tried to make something work for
even longer, without producing anything working at all.

Also, I remember it that Kent Beck thought the projects ending had nothing to
do with the performance of it.

~~~
bena
The success or failure of C3 is a contentious point. However, I'm also wary of
the testimony from people who have a stake in XP being successful rather than
C3 being successful.

[http://c2.com/cgi/wiki?WasChryslerComprehensiveCompensationS...](http://c2.com/cgi/wiki?WasChryslerComprehensiveCompensationSuccess)

<http://calla.ics.uci.edu/histories/ccc/>

------
citizenparker
Can anyone clearly explain how these "laws of power" prove the author's point
regarding XP? I've read this twice now, and I still don't understand the
connection.

It seems like French is saying that these laws explain why some people
wouldn't want to pair with some other people. I don't think anyone practicing
XP would dispute that some pairs just aren't meant to be. However, I don't see
how that leads to a failure of XP in general.

------
known
Extreme Programming works well for debugging code (not development)

------
wallflower
There is no need to pair program all the time. Like many things in XP,
adopting them all fully all the time is overkill. We don't do pure XP. We
don't do pure Agile/Scrum. We do what works for our company and with our
personalities and with our projects.

Pair programming works on our team very well in specific sets of circumstances
(e.g. something has to be built by a certain deadline) and by combining forces
(and sharing the pain) you improve your odds of getting it done and getting it
done in a quality manner.

I hate the term "driving" as it applies to pair programming. "Can I drive
now?". Argh.

------
CodeMage
Yet another oversimplification. The 48 Laws of Power are certainly present in
everyone's behavior, but it's a bit of a stretch to label them as the sole
culprit for XP's failures.

~~~
jamlee10
Where is the claim that the 48 Laws are the _sole_ culprit?

------
pj
This xp post isn't that interesting, but the laws of power that it links to
are
[http://www2.tech.purdue.edu/cgt/courses/cgt411/covey/48_laws...](http://www2.tech.purdue.edu/cgt/courses/cgt411/covey/48_laws_of_power.htm)

------
stcredzero
Linkbait-ish title. It's more like: "Why Extreme Programming doesn't take
hold."

------
vlisivka
XP and SCRUM can increase my productivity up to 300%. But, after 5 years of
successful XP and SCRUM practice, I burned out. I just cannot think about
work. Long vacations helps me a lot, but for short period of time - 1 month
vacation restore my productivity for about 6 months only.

How to classify that? As success or as failure?

~~~
nickashley
If it increases your productivity up to 300%, that means that you can work for
5 months, then take a month off. You will still get ~30 months worth of work
done in a year. So thats a huge success.

~~~
vlisivka
You are right in general case. In my case, I was responsible for few large
subsystems (Linux and related stuff, automated testing and continuous
building, packaging, deployment, automating of common tasks, configuring,
support and troubleshooting, training, documentation, reviewing, enforcing
best practices, developing of development standards, predicting future
problems, etc.). I just cannot leave that project for long period of time,
because large amounts of tickets must pass through me in some way
(investigation, suggestion, implementation, reviewing/fixing, approving).

I solved problem by training team, which replaces me. Then I leaved my work
(IMHO, crisis is best time for that). Team works slower than me. Their
solutions are not so good, because nobody has picture of whole project in his
head. However, they can continue to work, while I cannot. As I can see, this
scenario is typical.

IMHO, problem with XP and SCRUM that they producing too much load on the few
competent persons. Overall result is better than with traditional methods, but
competent person burns much faster, because they contribute more than others.

It is hidden magic beyond the process - XP and SCRUM just delivers task to
competent person much faster than any other process. The drawback is that
there no reason to grow for other developers, thus load on competent persons
tend to increase over time. Pair programming and peer reviewing helps when
people are roughly equal, but that is rare.

If we try to model situation, then we will see few major stages in evolution
of project and/or group:

    
    
      * fast growing of project and/or group until physical limit of few key people will be hit;
      * degradation of group, because key people leave project, until there no overloaded people;
      * stagnation.
    
    

PS. I spent last few months to improve me in sport-dancing. I meet new very
funny girl. I plan to work next 2 months as instructor for wind-surfing at
Black Sea (Eastern Europe). I hope, it will help.

