Some software development projects have more than one person specify requirements/stories. Thus, the client "voice" cannot be kept to a single person. Opposing interests sometimes exist as well. Therefore, create a CustomerTeam as part of the team. Their job is, together, to speak to the DevelopmentTeam? with one voice.
Related Wiki Pages:
Other links: Egroups:This should be treated by making the business people make the business decisions. Do no work until they give you clear priorities on what to do first. Anything else is perilous in the extreme.
Ignoring reality is what is really perilous. Like it or not, in many cases the development team is the only point of contact between competing interests. In these cases, the best approach is for the development team to come up with a plan and then get acceptance from each of the parties. A work stoppage is highly unlikely to create organizational changes.
Pick a person with power that you want to talk to. Whenever someone else tells you anything, tell them that you are going to to have to talk to that other person first. If you really have organizational issues, and you can swing it without getting fired, this will sort them out.
An option (of last resort) that was mentioned elsewhere was to give each competing group its own budget: "Each of you three groups has 20 points to spend on the next iteration. You can 'spend' them on whatever stories you most want. If you people want to work together to pool your resources, we'd think that's great."
I like the idea on PostItVote ...
With regards to my ExtremeProgrammingForOne project SystemForManagementOfCasualStaff, I received an email and a phone call from managers in other departments of the University inquiring as to the progress of my system and when they would be able to "have a look at it". My employer had been "selling" the system to other departments in an effort to increase the perceived value of the development in the eyes of other parts of the University management. This presented some interesting problems. The nature of XP is that I was working to a single group�s requirements, in fact working very specifically to their requirements. I was now wondering how to handle disparate groups of customers when I was pressured to meet their requirements as well. Having four customers rather than just one already had its difficulties, so the question was whether to develop with a new group of customers while ensuring that the acceptance tests for the original group were still met, or whether to split the product into a new version for each disparate group. -- GarethCronin
I concur with the above. There is usually no mechanism for the development team to force multiple customers to resolve their differences. It is difficult to even getting the competing voices to talk among themselves, much less get one group to agree to defer their issues in favor of another group. It usually falls to the development team to work out a compromise approach and present it to each of the competing voices. The trade offs are made by the development team and accepted by the various customers. --WayneMack
For more XP implementation issues, see ExtremeProgrammingImplementationIssues