Glenn Vanderburg has a great presentation available on InfoQ titled Craft and Software Engineering. In it, he describes where Software Engineering came from, some of the fallacies, and a direction to make it more like other Engineering disciplines. It's a great talk and moves quite well through the content. I'd recommend it to anyone involved in software development.
One of the things he talks about is feedback, and how the different XP provide feedback at different levels of granularity, and at different timescales. He also discusses this in his 2005 paper XP Annealed. Here's what this looks like in a table:
|system metaphor||classes and interfaces||minutes|
|unit testing||statements and methods||seconds|
In his paper, he goes on to describe how the nested levels of feedback are effective and efficient because the practices support each other, and cover for each other. Each practice, at each level of granularity and timeframe, covers and is covered by nearby practices.
Observation: The feedback can be broadly classified as technical at the lower levels, and business at the higher levels. Taken broadly, there are only two types of roles needed to implement the project. Technical (developers) to work out the design and testing, and business (non-technical) to provide the vision, the priorities and acceptance criteria.
Taking it one step further, putting these people together, as one collocated team, would be the most effective way to facilitate this communication. Nothing original here, but it seems to be a natural progression. It minimizes the number of hops that need to happen for any communication.
That's not to say there is no room for specialists, for things such as the environment, deployment, acceptance testing, UI design, and so on. However, they should all be part of the same collocated team.