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

[Note: this post was heavily edited on Jan 18th to take into account comments on the earlier version.]

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 like tuning an engine. It is straight-forward to explain, learn, and implement. Whereas, moving from conventional management to self-managing teams sounds like moving from steam to internal combustion. It is completely different and not well understood. But wait, what exactly are self-managing teams?

The terms “self-organizing,” “self-managing,” and “self-directing” have been used to mean many things, but are generally thought of as being in the same ballpark. In this post I will use the term “self-managing.” While looking for other writing on the topic prior to writing this post, I found that it is a poorly defined topic within the Agile literature.

What the Heck is a Self-Managing Team Anyway?
What sort of management does self-management apply to? What is the scope? Does it just apply to how I manage myself on my pre-assigned tasks? Does it only apply to project management? Does it mean dealing with hiring and firing? What about budgets? Some folks have taken it to mean that there is no manager, that the Scrum Master is the manager, etc. Sure, there are lots of short sections on self-managing teams in Agile 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 self-management 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.

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.

I had better luck finding reference material on self-management by looking outside of software development all together. 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 software 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.

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

Apparently, people have been promoting and practicing self-managing teams completely outside the realm of software development for quite a while. While it holds promise, it does not yet seem to have become a widespread practice. If it 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?

Even though self-managing teams are not well defined or described in Agile, it doesn’t really matter. There are actually many no-brainer “self-management” oriented Agile practices that are straight-forward and beneficial in their own right. The fact that they may get us closer to creating self-managing teams is a side benefit.

Next: "No Brainer Self-Management Practices in Agile"