Team Preservation vs. Prioritization

Keeping a team together is important, but not to the point where prioritization is hard.

Shared services teams are a necessity and they won't go away. The problem with them is that backlog prioritization is hard. You need to identify a product owner that is effectively a proxy to all the other users. This proxy's job is thankless; he or she has to make multiple competing stakeholders agree on priorities without an incentive to collaborate.

One way of solving this issue would be to group and disband teams as projects come and go. The Storm, Norm and Perform [1] theory for teams suggests that we keep teams together as long as possible and this approach would go against it.

So how would I solve this difficult problem?

I thought about:

1. Have a proxy for clients responsible for accommodating and negotiating priorities across stakeholders.
2. Dedicate resources or hours to specific stakeholders.


3. Form/Disband teams as projects come and go.
4. Create a cap and trade system similar to the one described on [2].

Lately, I have been leaning towards option 4 a lot. In short, every stakeholder is given a number of hours, or percentage of the team's time; a cap. They are allowed to negotiate their hours (or points) with the other stakeholders, but once the iteration, or some other time period starts, any points/hours that were not used would be forfeited in a use it or lose it fashion (I still have to think this one through).

This approach is not infallible. It can lead to context switching if all stakeholders decide to exercise their options in a specific, or worse, all iterations.

On the other hand, this could lead to some interesting behaviors, where certain stakeholders with medium priority projects could negotiate their caps at a premium with stakeholders that are "desperate" for completing projects. In other words, it rewards collaboration. It also allows the shared services team to measure how much a stakeholder "conceded" or not, eliminating the squeaky wheel effect [3].

Another interesting consequence is that it would encourage better portfolio management on the stakeholders’ part. I don't mean to reduce acceptance to change, but committing the team to a task/story that has low return value, would equate to throwing away money.

The cap and trade system seeks to reduce conflict resolution for all involved and give an incentive to negotiation and collaboration among stakeholders. I have not implemented such a system and have not completely thought it through, but it seems promising.

Besides all of that, it could lead to an interesting game.

What problems do you think I'm going to encounter? How did you solve this problem before? What were your good/bad experiences?

Please leave a comment below :)

[1] http://changingminds.org/explanations/groups/form_storm_norm_perform.htm
[2] http://www.americanprogress.org/issues/2008/01/capandtrade101.html
[3] http://en.wikipedia.org/wiki/Squeaky_wheel