For those of us who currently manage development teams and the work they carry out, sometimes it feels like we're one of those plate spinners you see on a variety show or busking on the street:

We're trying to keep many plates spinning at once. We have the team objectives (their missions), we're managing the ability to deliver on the objective (clarifying requirements, removing impediments), we ensure the teams have the right people with the right skills, we're hiring, and we look after our team members' professional development and individual performance. On top of this, we're trying to create high-performing teams that are getting into our customer's real needs and moving from just delivering software to making an impact and delighting our customer.

"We could reduce the number of plates that we're trying to spin," said no organization that I've ever worked for, ever. So, the only viable alternative that we have is to make some of the plates self-spinning:

Leading a self-organizing team can be somewhat like watching your first child take their first steps without you; you really want to be there for them and support them in case they fall over, but if you're too hands-on, you know that you're going to hinder their development.

Situations will vary; some of us will have existing organizational structures in place, and some of us will be much freer in terms of our choices and how we set things up. In part, this is the reason start-up companies have been so successful in adopting Agile practices; they've started with a clean slate.

The one thing that I have learned, while tipping my hat to R Buckminster Fuller for the general sentiment, is that we can't always change the existing system, but we can make a new one that makes more sense.