Welcome to the Korean edition of Extreme Programming Installed. Almost two years have passed since the book came out, and I welcome the chance to add a little perspective from those two years, in this new introduction.
What I have learned since the book came out has to do with the rules and practices of XP. When we wrote the book, we thought that it was important to do the practices exactly, in order to be doing XP. When people tried XP and varied from the practices, I was very insistent that they should do the practices as described by Kent Beck, and as described in our book.
Over time, people have argued that the specific practices are not what is central to XP, but that it is instead some spirit, or some principles, that form XP’s basis. They say that if you have this spirit, if you understand these principles, then you understand XP. I believe that this view is correct, but it does not mean to begin by inventing your own XP.
In the martial arts, students are taught at the beginning to do the forms or kata exactly as the instructor teaches. Later – much later - they begin to break the rules, and finally, even later, they become free to adjust the rules to their own situation.
Extreme Programming should be approached in this way. The practices are not the end of Extreme Programming, but they are the beginning. At the beginning, I believe that you should learn the rules, follow them exactly, push them to the limits. You should be as “extreme” as possible. Do not try to find the limits until you have learned to do the practices as described in the books. And, if possible, please try to work up to doing all the practices together, before adjusting any of them very much. The practices work together, and it’s best to learn them all and experience them together, if possible.
Your situation may not permit that, and if so, do the best you can. But if possible, doing the practices as simply as possible is your best way to learn XP.
What do I mean by simple? Let me go quickly through some of the practices as we now describe them, and say a few words about good ways to try each one.
Whole Team -- formerly On-Site Customer
The whole team should work together in one room. All the programmers, and all the customers. You may have a private room for phone calls or other privacy needs, but try doing all the work in a single room. Working together in one room makes most teams twice as effective as working separately.
And you do need a customer or customer team. You’ll be tempted to be “more efficient” by letting the customer write requirements and send them to you. Until you have worked directly with someone who understands the requirements, you’ll not understand how valuable it is to have them there, instead of represented by their words on paper or in electronic form.
Try to do the planning game just as we describe it. In Release Planning, let the customer explain the stories, then the programmers estimate how difficult they are. Don’t worry about being exact: your velocity calculations will deal with that. You need to estimate which stories are larger, and which are smaller. Use a small scale, perhaps just 1, 2, and 3.
Do iteration planning as we describe it also. Do the task planning as a group: this is an important design step. Let the people who sign up for things make the final design decisions, but sketch the design as a group.
Ship real running software to your customer, every two weeks. Yes, even in the first two weeks of the project, and every two weeks thereafter. This /is/ possible. Try it, you’ll like it.
Customer Tests -- formerly Acceptance Tests
The failure to have customer-owned acceptance tests is one of the most common mistakes in XP. Get acceptance test definitions from your customer in every iteration. Help the customer define those tests; give advice. Implement those tests and show your customer that the system does what was asked for. The customer will learn to create better tests and better features, and everyone on the project will know just where you stand. Do not wait for a tool to write acceptance tests. Program them just like any other program or test. Let the tools evolve over time. The important thing is to have the tests.
Push hard to keep the design simple. At every point in time, the design should be just barely sufficient for the current stories. Do not focus on future stories: let refactoring take care of that.
Work together in pairs, and switch pairs often. The power of this technique is very high. You will get better code, better understanding, and most of all, a better team. Write every line of production code with two programmers working together.
Test-Driven Development -- formerly Unit Tests
Use Test-Driven Development. Write a small test, make it work, write another test. Try to write new code only when you have a failing test that tells you the code is needed and what it should do. This technique produces wonderful code. It produces a large number of very accurate tests. It prepares you for refactoring. And best of all, it reduces stress. When you have lots of tests, you have no fear of changing your program when it needs it.
Design Improvement -- formerly Refactoring
I renamed this practice to remind us that we need to be improving the design all the time. If you are experiencing surges in refactoring – times when there is a lot of refactoring to do – that tells you that you aren’t doing enough small refactorings as you go along. Strive always to check in code that runs all the tests, and that is as clean as possible.
Team Code Ownership -- formerly Collective Ownership
Everyone on the team has the right to improve any code at any time. This includes improving the tests, and of course includes running all the tests. And remember pair programming while you improve the code. By making all the code available to all the minds on the project, we remind ourselves that this is a team effort, and we get the benefit of everyone’s ideas. In addition, everyone learns from everyone else.
Keep your code in the project, not in your sandbox or on your local computer. Code that is checked out for a long time is hard to check in. When integration of the code seems difficult, it is a sign that you need to do it more often. The best teams integrate many times per day. Be one of the best teams in this regard.
Sustainable Pace -- formerly 40 hour week
We don’t really care how many hours you work. But if you are working well, you will probably find that around six hours of intensive pair programming is the most you can do while remaining effective. Measure your team performance in stories done per iteration, and pay attention to the rate at which you are inserting defects. Find the optimal pace for your own team. That pace is more likely to be around 40 hours per week than around 60. Whatever the ideal pace is, you need to find it, and work at that pace.
Please try the XP practices in their pure, “extreme” form. When you have mastered them as written, you will have learned what XP has to offer you, and you will be ready to move beyond simple rule following into breaking with the form, and creating your own form. It is best to start at the beginning, and master the basics. Then go beyond them.
I hope you enjoy Extreme Programming, and I feel sure that if you will give it a chance you will find it useful. If I can help you in any way, feel free to send me e-mail.
Good luck, and good work!