Empowerment and Leadership: Keys to Self-Organization

by Jim Highsmith, Director, Agile Project Management Practice

There seems to be a bit of confusion within the agile community about the concept of self-organization. To some it seems to be a euphemism for anarchy and an excuse to rail against management in general and project management in particular. I think this "anti-management" faction helps critics relegate agile to a "small-project, fringe" movement, which is unfortunate. Self-organizing isn't about anarchy or lack of leadership, it's about empowerment (or in the old school, delegation) and style of leadership.

At its core, empowerment or delegation is about decisionmaking, and in particular about framing decisions and the decisionmaking process. For example, should a single feature team in an eight-feature team project get to make its own architecture decisions without considering the whole project team's needs? Of course not, but I've seen an organization in which multiple-feature teams, working on the same project, were encouraged to be "self-organizing" to the extent that the overall project rattled apart. So there are several important questions here: What decisions does the project team get to make independent of others? When decisions impact multiple teams, what is the decisionmaking process? What is the decisionmaking process within a team? And when do leaders/managers (both organizational and technical) get to make decisions?

W. L. Gore, makers of Gore-Tex and many other products, has an interesting analogy for decisionmaking it calls "hole-in-the-boat." Individuals and teams try to imagine decisions as poking holes in the organizational "boat." If the hole is above the waterline, the person/group should go ahead and make the decision. However, if they perceive that the hole might be below the waterline (and therein sink the boat), the decision should be made in conjunction with others.

Empowerment or delegation answers the question "where should the decision be made?" In a self-organizing environment, decisions should be delegated to the feature-team level as much as possible, but those decisions that "poke holes in the boat" have to be resolved among various interested parties and not within a single-feature team.

Once the question of "where" has been answered, the next question is "how" the decision should be made. In effective self-organizing groups, some type of participatory decisionmaking process makes sure that everyone has an opportunity for input and discussion on the decision. Self-organization should not imply a consensus process (as in everyone has to vote one way), but a participatory process in which everyone has input. However, even in self-organizing teams, leaders occasionally have to step in and make decisions.

A second aspect of self-organizing teams is leadership. Some think that self-organizing teams don't have a manager or leader and that "leadership" revolves around the group in various circumstances. The correct term for this is a "self-directed" team, and they have not proved to be very effective. I think agile teams need leaders, but that the style of leadership is different. In my first book, Adaptive Software Development, I contrasted the traditional command-control leadership model with one I called leadership-collaboration. There is too much evidence in management literature and practice that leadership is important to dismiss it as some agile factions do. Leadership is important to success.

There are other aspects of self-organizing teams, but decisionmaking and leadership are key. If you find your organization being drawn into an agile implementation by an anarchist faction, look around for someone else with a more workable understanding of self-organization.

-- Jim Highsmith, Director, Agile Project Management Practice