The programmer is the heart of XP. Actually, if programmers could always make decisions that carefully balanced short-term and long-term priorities, there would be no need for any other technical people on the project besides programmers. Of course, if the customer didn't absolutely need software to keep the business running, there would be no need for the programmers, so it won't do to get too big-headed about being the vital programmer.

On the surface, being an XP programmer looks a lot like being a programmer within other software development disciplines. You spend your time working with programs, making them bigger, simpler, faster. Beneath the surface, however, the focus is quite different. Your job isn't over when the computer understands what to do. Your first value is communication with other people. If the program runs, but there is some vital component of communication left to be done, you aren't done. You write tests that demonstrate some vital aspect of the software. You break the program into more smaller pieces, or merge pieces that are too small into larger, more coherent pieces. You find a system of names that more accurately reflects your intent.

This may sound like a high-minded pursuit of perfection. It is anything but. You try to develop the most valuable software for the customer, but not to develop anything that isn't valuable. If you can reduce the size of the problem enough, then you can afford to be careful with the work you do on what remains. Then, you are careful by habit.

There are skills that you must possess as an XP programmer that are not needed or at least not emphasized in other styles of development. Pair programming is a learnable skill, but one often at odds with the tendencies of the sort of people who typically get into programming. Perhaps I should state this less equivocally—nerds aren't generally good at talking. Now, there are certainly exceptions to this, and it is possible to learn to talk with other folks, but the fact is that you will have to communicate and coordinate closely with other programmers in order to be successful.

Another skill needed by the extreme programmer is the habit of simplicity. When the customer says, "You must do this and this and this," you have to be prepared to discuss which of those items is really necessary and how much of each. Simplicity also extends to the code you write. A programmer with every last analysis and design pattern ready at hand will not be likely to succeed with XP. Of course, you can do a better job if you have more tools in your toolbox than if you have fewer, but it is much more important to have a handful of tools that you know when not to use, than to know everything about everything and risk using too much solution.

You will need skills that are more technically oriented as well. You have to be able to program reasonably well. You have to be able to refactor, which is a skill with at least as much depth and subtlety as programming in the first place. You have to be able to unit test your code, which, like refactoring, requires taste and judgment to apply well.

You have to be willing to set aside the feeling of individual ownership of some portion of the system in favor of shared ownership of the whole system. If someone changes code that you wrote, in whatever part of the system, you have to trust the changes and learn from them. Of course, if the changes are wrong-headed, you are responsible for making things better.

Above all, you must be prepared to acknowledge your fears. Everybody is afraid—

Without courage, XP just simply doesn't work. You would spend all of your time trying desperately not to fail. Instead, if you are willing, with the help of your team, acknowledge your fears. Then you can get on with the business of belonging to a team having fun writing great software.

The customer is the other half of the essential duality of extreme programming. The programmer knows how to program. The customer knows what to program. Well, not at first, of course, but the customer is willing to learn just as much as the programmer is.

Being an XP customer is not easy. There are skills you have to learn, like writing good stories, and an attitude that will make you successful. Most of all, though, you have to become comfortable influencing a project without being able to control it. Forces outside your control will shape what actually gets built just as much as the decisions you make. Changes in business conditions, technology, the composition and capability of the team, all of these have a huge impact on what software gets delivered.

You will have to make decisions. This is the hardest skill for some of the customers I have worked with. They are used to IT not delivering half of what they promised, and for what is delivered to be half-wrong. They have learned never to give an inch to IT, since they are bound to be disappointed anyway. XP won't work with such a customer. If you are an XP customer, the team needs you to say with confidence, "This is more important than that," "This much of this story is enough," "These stories together are just enough." And when times get tough, and they always get tough, the team needs you to be able to change your mind. "Well, I guess we don't absolutely have to have this until next quarter." Being able to make decisions like this will at times save your team, and reduce their stress enough so that they can do their best for you.

The best customers are those who will actually use the system being developed, but who also have a certain perspective on the problem to be solved. If you are one of these customers, you will have to be aware of when you are thinking a certain way because that is how things have always been done, rather than because of some essential quality in the problem. If you are a step or two removed from actually using the system, you will have to work extra hard to be sure that you accurately represent the needs of the real users.

You will have to learn how to write stories. This may seem like an impossible task at first, but the team will give you the gift of copious feedback on the first few you write, and you will rapidly learn how much ground to cover in each story, and what information to include and exclude.

You will have to learn to write functional tests. If you are the customer for an application with a mathematical basis, you will have an easier job—a few minutes or hours with a spreadsheet will suffice to create the data for a test case. Or perhaps your team will build you a tool to make entering new test cases easy. Programs with a formulaic basis (like workflow, for example), also need functional tests. You will have to work closely with the team to learn what kind of things it is helpful to test, and what kind of tests are redundant. Some teams may even assign you technical help for choosing, writing, and running the tests. Your goal is to write tests that let you say, "Well, if these run, then I'm confident the system will run."

Finally, you will have to demonstrate courage. There is a way from where you are today to where you want to be. This team can help you find it, if you will help them find it.

Since a lot of testing responsibility lies on the shoulders of the programmers, the role of tester in an XP team is really focused on the customer. You are responsible for helping the customer choose and write functional tests. If the functional tests aren't part of the integration suite, you are responsible for running the functional tests regularly and posting the results in a prominent place.

An XP tester is not a separate person, dedicated to breaking the system and humiliating the programmers. However, someone has to run all tests regularly (if you can't run your unit and functional tests together), broadcast test results, and to make sure that the testing tools run well.

As a tracker, you are the conscience of the team (think Jiminy Cricket, but with better clothes).

Doing good estimates is a matter of practice and feedback. You have to make lots of estimates, and then notice how reality conformed to your guesses. Your job is to close the loop on feedback. The next time the team is making estimates, you need to be able to say, "Two thirds of our estimates last time were at least 50% too high." On an individual basis, you need to be able to say, "Your task estimates are either way too high or way too low." The next estimates to come out are still the responsibility of the people who have to implement whatever is being estimated, but you have given them the feedback so that when they come out, they can be better than last time.

You are also responsible for keeping an eye on the big picture. Halfway through an iteration you should be able to tell the team whether they are going to make it if they follow the current course or if they need to change something. A couple of iterations into a commitment schedule you should be able to tell the team whether they are going to make the next release without making big changes.

You are the team historian. You keep a log of functional test scores. You keep a log of defects reported, who accepted responsibility for each, and what test cases were added on each defect's behalf.

The skill you need to cultivate most is the ability to collect the information you need without disturbing the whole process more than necessary. You want to disturb the process a little, to keep people aware of how much time they actually spent on a task in a way they might not be aware of if you didn't ask. But you can't be such a pain in the neck that people avoid answering you.

As coach, you are responsible for the process as a whole. You notice when people are deviating from the team's process and bring this to the team's attention. You remain calm when everyone else is panicking, remembering that in the next two weeks you can only get two weeks' worth of work done or less, and either two weeks' worth is enough or it isn't.

Everyone on an XP team is responsible for understanding their application of XP to some extent. You are responsible for understanding it much more deeply—what alternative practices might help the current set of problems; how other teams are using XP; what the ideas behind XP are; and how they relate to the current situation.

The most difficult thing I have found about being a coach is that you work best when you work indirectly. If you see a mistake in the design, first you have to decide whether it is important enough that you should intervene at all. Every time you guide the team, you make them that much less self-reliant. Too much steering and they lose the ability to work without you, resulting in lowered productivity, lowered quality, and lowered morale. So, first you have to decide whether the problem you see is enough of a problem that you need to accept the risk of intervening.

If you decide you really do know better than the team, then you have to make your point as unobtrusively as possible. For example, it is far better to suggest a test case that can only be implemented cleanly by fixing the design, than it is to just go and fix the design yourself. But it is a skill to not directly say what you see, but to say it in such a way that the team sees it, too.

Sometimes, however, you must be direct, direct to the point of rudeness. Confident, aggressive programmers are valuable precisely because they are confident and aggressive. However, this leaves them vulnerable to a certain kind of blindness, and the only cure is plain speaking. When you have let a situation deteriorate to the point that the gentle hand on the yoke can no longer work, you have to be prepared to grab the yoke with both hands and steer. But only long enough to get the team back on track. Then you have to let one hand drop again.

I want to say something here about skills coaching. I am always in the position of teaching the skills of XP—simple design, refactoring, testing. But I don't think this is necessarily part of the job description of coach. If you had a team that was technically self-sufficient, but needed help with their process, you could coach without being a techno-whiz. You would still have to convince the propeller-heads that they should listen to you. But once the skills are there, my job is mostly reminding the team of the way they said they wanted to act in various situations.

The role of coach diminishes as the team matures. In keeping with the principles of distributed control and accepted responsibility, "the process" should be everybody's responsibility. Early in the shift to XP this is too much to ask any programmer.

XP projects don't spawn a lot of specialists. Since everyone is pairing with everyone else, and the pairs float around so much, and anyone can accept responsibility for a task if they want to, there is little chance that dark holes will develop where only one or two people understand the system.

This is a strength, because the team is extremely flexible, but it is also a weakness, because from time to time the team needs deep technical knowledge. The emphasis on simplicity of design reduces the occurrence of the need for the pointy hat, but it will happen from time to time.

When it does, the team needs a consultant. Chances are, if you are a consultant you won't be used to working extreme. You are likely to view what the team does with a certain amount of skepticism. But the team should be extremely clear about the problem they need to solve. They will be able to provide you with tests to show exactly when it has been solved (in fact they will insist on the tests).

What they won't do is let you go off and solve the problem by yourself. If the team needs deep technical knowledge in an area once, they are likely to need it again. Their goal is to get you to teach them how to solve their own problem. So, one or two team members will sit with you as you solve the problem. They will likely ask you lots of questions. They will challenge your design and assumptions, to see if they can't find something simpler that will still work.

And when you are done, they will most likely throw away everything you have done and do it over themselves. Don't be insulted. Every day they do this to themselves a little bit, and probably once a month they throw away a day's work.

If you're the big boss, what the team needs most from you is courage, confidence, and occasional insistence that they do what they say they do. It is likely to be difficult for you to work with the team at first. They are going to ask you to check up on them frequently. They are going to explain the consequences of changes in the situation. For example, if you don't get them the new tester they asked for, they will explain exactly what they think that will do to the schedule. If you don't like their answer, they will invite you to reduce the scope of the project.

Coming from an XP team, this constitutes honest communication. They aren't whining, really they aren't. They want you to know as soon as possible when things are differing from the plan, so you have as much time to react as possible.

The team needs you to have courage, because what they do will sometimes seem crazy, especially if you have a background in software development. Some of the ideas you will recognize and approve of, like the strong emphasis on testing. Some don't seem to make sense at first, like pair programming being a more effective way to program and constantly refining the design being a lower-risk way to design. But watch and see what they produce. If it doesn't work, you can step in. If it does, you're golden, because you will have a team that is working productively, that keeps its customers happy, and that does everything they can to never surprise you.

This doesn't mean that the team won't screw up from time to time. They will. You will look at what they are doing, and it won't make sense to you, and you'll ask them to explain it, and the explanation won't make sense. That's when the team is relying on you to make them stop and take a look at what they are doing. You got to your position for a reason. The team wants to put that skill to work for them when they need it. And, frankly, to keep it out of the way when they don't need it.