Extreme Programming

Question

As developers and as professional engineers have you been exposed to the tenants of Extreme Programming as defined in the "version 1" by Kent Beck. Which of those 12 core principles do you feel you have been either allowed to practice or at least be a part of in your current job or others?

* Pair programming[5]
* Planning game
* Test driven development
* Whole team (being empowered to deliver)
* Continuous integration
* Refactoring or design improvement
* Small releases
* Coding standards
* Collective code ownership
* Simple design
* System metaphor
* Sustainable pace

From an engineers point of view I feel that the main engineering principles of XP arevastly superior to anything else I have been involved in. What is your opinion?

Answer 1

I consider myself lucky, all except "Pair programming" we can do it, but only to solve big issues not on a day-to-day basis. "Collective code ownership" is hard to achieve as well, not doing pair programming we tend to keep the logical next user stories from iteration to iteration.

Answer 2

We are following these practices you've mentioned:

• Planning game
• Test driven development
• Whole team (being empowered to deliver)
• Continuous integration
• Refactoring or design improvement
• Small releases
• Coding standards
• Collective code ownership
• Simple design

And I must say that after one year I can't imagine working differently.

As for Pair programming I must say that it makes sense in certain areas, where there is a very high difficult area or where an initial good design is essential (e.g. designing interfaces). However I don't consider this as very effective. In my opinion it is better to perform code and design reviews of smaller parts, where Pair programming would have made sense.

As for the 'Whole team' practice I must admit that it has suffered as our team grew. It simply made the planning sessions too long, when everybody can give his personal inputs. Currently a core team is preparing the planning game by doing some initial, rough planning.

Answer 3

• Whole team (being empowered to deliver)
• Small releases
• Coding standards
• Collective code ownership

But then, I do work in a mission-critical development team that's quite conservative. I don't necessarily thing XP is a good way to develop, you must find a way that's right for you and ignore the dogma.

Answer 4

We've done everything except small releases and it's been great. I can't imagine working any other way. From my experience, the tenets I value most are:

• Continuous integration (with a solid test suite).
• Collective code ownership.
• TDD
• Team empowerment and decision making.
• Coding standards.
• Refactoring.
• Sustainable pace.

The rest are very nice to have too, but I've found that I can live w/o pairing so long as we have TDD, collective ownership, and refactoring.