I’m thinking this for a couple of different reasons…

To start with, I think that the voting will show what the team feels is the highest priority item. I don’t think that a team should focus on roles at this point; we are all simply team members (not analysts, not designers, not developers). If a particular thought doesn’t receive more votes than another item, that’s simply a statement by the team that they don’t think that it’s as important as other alternatives. The point of the retrospective is to focus on the team (not individual roles).

The second thing that stands out is that if you are repeatedly being out-voted, you need to help the other team members see the value in the items that you are trying to fix. If others see the value and believe in the thought, they will vote for it and it will be addressed. In the situation that you describe above, I would focus on effectively communicating what the thought is and why it’s important.

The third point is that I don’t think that it should be in the power of the facilitator to trump the decisions of the team (which they decide by voting) if they think that other items are higher in priority. I believe that swaying votes, voting, or changing the teams decision are all bad things for facilitators to do during any type of session. The role of the facilitator should be to facilitate the meeting, not to participate in the outcome or take sides.

The last thing (and likely the most relevant) is that I think that the real anti-pattern is in relying in the retrospective to be the only place where issues, concerns, smells, etc. can be addressed. Retrospectives are great, but they shouldn’t be the only opportunity to address items. If you are passionate enough about something, you should focus on fixing it as soon as possible.

If all else fails and you are passionate about getting something changed, you can often start to address the items yourself. Forgiveness over permission can be powerful in extreme cases

I think any new professional HCI/d-er is going to be constantly put in situations like what you describe, where the perspectives for which we advocate are not going to have a voice in the conversation without us being assertive and effective. My guess is that you are better at that communication with each meeting.

My short experience as a user experience guy in a room filled with programmers is that they are very used to quickly focusing on what they can do for this week. There isn’t an unwillingness to explore ideas, but there is pressure (and a personal need, I think) to have those crazy design ideas translate into something tangible that has business value. Unless one works in a design research firm that doesn’t need to implement, or doesn’t have a bottom line to follow, this will always be the dynamic.

The culture changes only when the seemingly slower, crazy design approach yields better results. Patience is a rare commodity.