Extreme Programming, does it work?

Question

I'm wanting to hear from some people who have actually done extreme programming.

Does it work? Well?

Is it sustainable over the long term?

Thanks!

Answer 1

If you haven't already read it, you must read Good Agile, Bad Agile and the ensuing comments.

Answer 2

I think it would be a very expensive proposal to do it like this full-time, but I know that whenever I end up in session with another programmer where we're working together at the same screen to debug something, it tends to produce very good code very quickly. So a nice process in a traditional shop to encourage pair programming a little more often might be very beneficial.

Answer 3

It works wonders if you work at it.

Life is like a sewer. What you get out of it depends on what you put into it. -Tom Leher

It is sustainable, productive, and effective long term. It is harder for some people and easier for others but if you can strike a nice balance in your team you can use XP successfully.

I'd recommend not using it for ALL your coding, but definitely for the stickier issues and the design phase, it can work wonders.

Answer 4

It depends on a lot of factors.

Also it does have a little bit of bad reputation so even if you use it do not speak too loud about this to your customers :)

Answer 5

In practice, it works but Extreme Programming require more money because project "never end" until a stop is given. Human tend to add a lot of [not useful] thing because the owner can add stuff when he wants.

I personnally prefer something like Scrum more because it requires a little bite more planning.

Answer 6

I've done little of XP myself, but I've worked with a team which used it.

It's main value is peripheral: it requires Unit testing (which is good), and unit testing forces de-coupled designs (which is very good).

Beyond that, most of it core principles (paired programming; YNGNI) basically just minimize the damage caused by bad programmers.

Answer 7

Honestly, it's how I started in C++ years back - though in the mid-90s it wasn't called that.

I found it very useful. In the specific [hobby] project I worked on, the heavy math/algorithm lifting was done by my friend Jeff, while I was there for syntax/logic checking.

For the parts I wrote, we swapped - I found the graphics libs to use, and learned them, while Jeff was the syntax nazi.

Answer 8

I worked on a project (as an intern) that had a VB6 client-server application.

I was to maintain it, but if I didn't understand it to go to my mentor for help. He was a primarily C# programmer. I'd look over his shoulder as he would code things, and I was supposed to learn. I learned much, and acted as a sort of biological compiler for him "Wrong Language, boss". And if he started doing something I didn't understand, I'd ask him about it, and he would either explain, or simplify the code (because if I didn't understand it, neither would my replacement).

I'd give it a thumbs up, but I'd also march into Hell for that mentor/boss 2.5 years after I left the company.

My current coworkers? Not so much. I'd fight it here.

Answer 9

How about three years? We have a team that has been doing agile (SCURM and XP) practices for the last three years. It has not missed a date, hit budget within 1 or 2 percent, often has zero defects found in user acceptance testing with only 2 or 3 low or medium defects on production with a user base over 20,000. This is in an environment that is primarily waterfall and has many dependencies.

From time to time, the business will ask if they could save money by skipping some of the XP practices, in particular, pairing or automated testing. As a result of these questions, we pulled some historic data. Once it become apparent the cost of a late or failed project and the cost to bring a failed project back in line, it became clear that the engineering practices are very cost effective and enabled a sustainable pace of development.

The success we have experienced with the 3 year team, we have seen with a second team for over 2 years and a number of one year teams.

The beauty of an XP project is that you delivery on what matters to the business. They receive value incrementally and begin to see a return on investment from the first release onward. The business partner is better able to gage the benefit of each feature delivered, gains confidence in the team's ability to deliver and is better able to decide if a feature has value.

For a waterfall project, because scope is fixed, the business will often stuff all they can in the scope document not know what they will need. With the prioritized product backlog list, and the ability to change often and quickly, the business will focus on the work in prioritized oder. As a result you deploy an application that gets used.

Answer 10

I've worked in a very successful extreme programming team. I joined within the first few weeks of migrating to XP. During the four years that I worked on the project we changed the codebase (and the company!) beyond all recognition.

It's fair to say that we had a very experienced team with a lot of people from different backgrounds and a management that didn't really care about methodology - just that they got results.

You do need experienced, motivated developers to do XP. You certainly couldn't just copy what we went through and expect to get the same result - any more than you could expect to copy a formula for a good party. This is down to what they call "social complexity".

It can work. I've been very happy with it :-)