The Use of Self-Managing Teams Outside the Context of Software Development

Even after becoming an Agile convert, I've still struggled with accepting Self-Managing teams wholeheartedly. There's just something about it that doesn't feel quite right. Before launching into a comment that describes Self Managing Teams 101, please bear with me. Yes, I've seen it in action and read all about it in the Agile literature and gotten various opinions on it from other Agile folk. The feeling persists.
I'm not against self-management, but here's what troubles me. Most of what you need to do to become Agile requires only re-arrangement of what you are already doing. For instance, managing a backlog is still a process of deciding which work to do and in which order to do it, it isn't something that boggles the mind and makes people say "some people might be able to do that, but I don't see how we could." Managing what work to do with a backlog is more like tuning the engine rather than moving from steam to internal combustion. Managing a backlog is straight-forward to explain, learn, and implement.
Whereas, moving from conventional management to self-managing teams is like moving from steam to internal combustion. It is completely different and not well understood. There is very little on the subject in the literature. Sure, there are lots of short sections on it in books and articles, but it is not much more than a vague description of the concept repeated in different ways by different authors. This is not a criticism, only an observation that it is an underdeveloped area of Agile.
In the Poppendieck's "Implementing Lean Software Development" there are four pages on "Self-Directing Work", most of which talks about project management. Kent Beck's "Extreme Programming Explained" takes self-management for granted without specifically talking about it. Ken Schwaber's book "Agile Software Development With Scrum" contains a couple of paragraphs on self-organization but mostly takes it for granted. In general, most of the material on the topic assumes that you will be doing it and there are practices which are meant to support it, but there is no in-depth discussion of exactly what it is and how to do it.
Part of my problem with the terms self-directing, self-organizing, and self-managing is that they are poorly defined. What is the scope? For instance, does it just mean how will I accomplish a task? Does it just mean deciding which task I personally will work on? Does it just mean project management? Does it mean dealing with hiring and firing?
In searching the web for a more in-depth treatment, I did find one really good article by Esther Derby in the December 2008 issue of Better Software Magazine entitled "What's a Manager to Do?" This article gives a good overview of the concepts as well as some pitfalls and how to avoid them. Even so, I was looking for something more.
At some point during my searching, I accidentally left off the keyword "Agile" and discovered that there are whole books on self-managing teams, and they have nothing to do with Agile development at all. I ordered three of them and am currently in the process of reading them. I'll post new entries as I go. So far, the most interesting thing is that the first printing for two of the books was 1993 and 2000 for the other one.
Apparently, people have been promoting and practicing self-managing teams in general, completely unconnected from Agile or software development, for quite a while. However, it does not yet seem to have become a widespread practice. That feeds into my concern that if self-management is still in its infancy in general, is it really a good idea to promote it in conjunction with all of the other parts of Agile which, IMHO, are much more straight-forward and are closer to our core-competencies as an industry?
I look forward to your comments. If you have pointers to good material on self-managing teams, please post those as well!
Here are the books on my reading list related to self-managing teams:
Business Without Bosses
Leading Self-Directed Work Teams
The Wisdom of Teams