Development team facade
One of Extreme Programming's practices is OnSite Customer (also see Martin Fowler's definition of OnsiteCustomer).
Although it is good if each programmer can constantly ask questions of the customer whenever they need to, it is not good if the customer has the same ability. Anytime the customer wants to ask a question, just being able to call up a developer kills that developers concentration, subsequently killing his productivity. On the other hand, if the developer is able to get an immediate answer to his question, it maximizes productivity.
The solution is to designate someone to run "interference" for the developers. Who runs this interference? In Brooks' The Mythical Man-Month, the role is assumed by the copilot, who attends all meetings, answers all technical questions, and acts as the general technical answer guru for the project. This leaves the surgeon (chief programmer) with all his time devoted to programming. In my own experience, I was the technical lead and ran interference for my team. Although I might not have made much of a contribution to our body of code directly on some days, my real accomplishment was enabling the other 8 developers to contribute 100 percent every day (8 * 100% is much more than 9 * 80%).
So what this really is is a facade for the development team. The customer is supposed to speak with one voice, and they speak to one person who will get them the answer or pass it along to a developer. Does this then break the facade? I don't think that a developer has to go through the team spokesperson to communicate with the customer, but it helps. In our case, it avoided anyone calling a developer back or stopping by our work area and standing over our shoulders for hours. I don't tend to think of email as a distraction, since you can just not check it. You might argue that most phones can have their ring disabled. Most can, but I like to keep the phone as an option for extreme development emergencies, such as when the CEO puts you on the spot in the middle of a seemingly innocent status meeting.
Devoted readers of Martin Fowler's bliki will note that in PleasingTheCustomer it says that a major source of enjoyment is direct developer-customer interaction. While I certainly agree with this, I do not think that it requires 100 percent all-day everyday direct interaction. Sometimes you just need to get things done... alone. Completed iterations, milestone deliveries, or whatever progression of steps your project goes through, are excellent times for everyone (business people and developers) to get together and party. In my experience this is usually enough, but if there needs to be more interaction to chase down a troublesome and elusive bug, then so be it. As always in agile development, people over process.