When you have a small XP team, you have a couple of choices with respect to coaching:

	* rely on group coaching - this might work if there are enough experienced XP people on the team, but I'm not sure what would happen during high pressure times.
	* coach from a remote site - the coach wouldn't need to be present all the time, just be available to ask questions and show up once in a while to observe.  I think this would be difficult to be as effective since the dynamics you'd observe when you were there may vary greatly from the dynamics when your not.
	* have a player/coach - the coach is also a developer.  This is similar to ArchitectAlsoImplements.  In fact, I would assume both would often happen together as the person who can coach best might be the best designer/architect in the group also... that's often been the case for me (XP or not).

On the XpCarolina project, I actually do all three of the above and it works great.  I'm a player/coach when I'm there (about half-time), and when I'm not I check in on the group, but this is not too big a deal since two of the members are relatively experienced at XP and have learned to coach by watching me (for better or worse), and the others are pretty well sold on it.

Having not been at it for as long as RonJeffries and KentBeck its hard to say what all the potential drawbacks of this are, but so far, so good.  -- KenAuer
----
We had some experience with this on the VcapsProject.  What we had was one person who knew XP fairly well, several experienced people who had tried various other name brand methodologies, and a couple of hack and slash programmers.  At the beginning the person who knew XP would suggest we solve problems using pieces of XP and explain how XP works.  Sometimes we would try those ideas out right away, sometimes we would wait.  It didn't take very long before everyone comprehended how it would work and was contributing equally. We found that by re-discovering XP together, step by step, everyone felt a much stronger sense of responsibility and empowerment.  The team became self coaching (group coaching) and was able to keep going even through the high-pressure times because we were all responsible for the process.  None of it had been handed to us easily.  We had to convince upper management and even some of our fellow developers to try new things.  When trouble came we supported and encouraged each other to keep following our new methodology and see it through, no matter how tight things got. --DonWells
-----
Don, I want to highlight something you said.  ''by re-discovering XP together, step by step, everyone felt a much stronger sense of responsibility and empowerment.''  I am finding this a common theme for methodology adoption, have heard several teams speak it in about the same words.  I'm trying to see how to say this formally and strongly and apply it widespread - the concept is turning out to be key.  cheers - AlistairCockburn