Here's a list of principles that I have come up with to help Project/Iteration Managers build a self-organising team:
Team Accountability:
The team needs to take accountability for its work. The team needs to own the estimates and feel that the team, as a whole, can achieve the work planned for the iteration. It needs to understand the priorities of the story cards and have an easy way to understand what the bottlenecks are. If the team needs to come to the iteration manager to find out what to do next, then they've turned themselves into a bottleneck. The team needs to be able to see if certain cards are stalled, and be able to take effective action to resolve it.
The most effective way that I've seen to manage this is to use a story wall with a clear queue of stories in the backlog. Devs, testers, analysts just pick up the next priority story from the queue and start working on it. They don't need to come and talk to the manager; they just do it. The team can easily identify constraints in the system (where the cards are piling up) and decide what to do about it.
Key to making this work, from my experience, is to eliminate the notion of single card sign-up. As soon as a single dev has taken ownership for a particular card, it has just introduced a point of failure into the system. Devs owning particular cards will be less willing to help others, less willing to pair, and less willing to rotate. Use just-in-time sign-up. This makes so many XP practices much more effective.
Make It Visible:
Contrary to popular wisdom, spreadsheets are the bane of self-organising teams. Any information that is important to the team that is locked in spreadsheets means that the team is dependent on the manager to find this out. Use big visible charts to demonstrate the progress through the iteration and through the release. Get the team to take responsibility for updating it. If the team doesn't do this, either change the approach (use a whiteboard rather than printouts, make sure that the charts are in the stand-up area) or make the team understands why this matters. This also includes the MSL (master story list): get it up on the wall. The team should be able to see all the stories in the release. They should be looking at what's in the pipeline. They should be identifying candidate stories for splitting in future iterations; they should be able to see and revise estimates where appropriate. They should be able to see how priorities change and how scope is being managed.
Embrace Change:
The team needs to take ownership for its process. The best way that I've found to do this is to actively encourage them to change it. Too often, in my experience, IMs are the great resisters of change. This is the opposite of what they need to do to build a self-organising team. They need to be a change agent, not a change bottleneck. If a team member sees something that can be improved, encourage them to try it out! Be their champion. Help them sell it to the team. But set up a feedback cycle that will allow you to minimise risk. This means that the team will be more likely to try it out ("I'll do anything for a week") and upper management will be more willing to buy in. The "new" XP practice of weekly cycles is a great way to do this. My observation is that after a while, this sort of change is self-sustaining. Team members are not afraid to suggest changes; they start actively thinking about how they can make things better.
Embody the Values (Be Congruent):
To set the culture for the team, the manager needs to lead by an example. The team will be more willing to trust you if your words and your deeds are aligned and are aligned with the values that the team aspires to. Question your actions: if i do this, will it be in accordance with or in opposition to the values we uphold.
I'm sure that others can suggest other priniciples that I'm missing, but I find this a good place to start.