Why Self-Organizing Teams are Better

Many people are confused about the concept of self-organizing teams. They either equate it with anarchy or confuse self-organizing with self-forming, self-directed or self-managing. What does self-organizing really mean and how is it different than all these other terms?

What are Self-Organizing Teams?

Let’s start with the concept of self-organizing teams. The term was included in the 12 Agile Principles behind the Agile Manifesto, developed in 2001:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

Some people characterize this as: self-organizing teams decide by themselves how to execute their tasks, manage their processes, and monitor progress. To me, this would have been better described as a self-managed team. I think that is what the authors of the Manifesto meant. It is about the team figuring out “HOW” to get their work done, not “HOW TO FORM THE TEAM”.

Similarly, the most current Scrum Guide references self-organizing teams six times. The way it is used it is clear that they are referring to how the team gets work done and not about how to organize the team.

The Source of Self-Organization in Agile and Scrum

While self-organizing was referenced in both the 2001 Agile Manifesto and the Scrum Guide, it actually precedes both of those. We can trace the source of “self-organizing” back to the 1996 HBR article that inspired Scrum, “The New New Product Development”. In that article, they described self-organizing as having three key characteristics:

“A group possesses a self-organizing capability when it exhibits three conditions: autonomy, self-transcendence, and cross-fertilization. In our study of the various new product development teams, we found all three conditions.

Levels of Self-Organizing Teams

Practically speaking, self-organizing is not something that is binary, on or off. What is more typical is that there are different levels of self-organization.

 

Richard Hackman provides a useful framework for looking at self-organization in his book, Leading Teams: Setting the Stage for Great Performances. Hackman looks at 4 different factors for team oversight and management including who provides the direction, who designs the team member composition, who monitors and manages the work, and who executes. Different team names are given based on whether management or the team does each of these things as shown in the diagram below.

Based on Hackman’s framework, most of the Agile and Scrum teams I work with would fall into the category of self-managing teams below.

Some Confuse Self-Organizing with Self-Forming Teams

I had a client recently who interpreted the term self-organizing to mean self-forming teams. They thought that teams within their organization would be expected to form every time there was a new problem. Richard Hackman calls these self-designing teams.

While the client could have a self-designing team every time there was a new problem, it is more likely that there is a one time decision on what teams will exist. Typically management makes the decision on what teams are needed and who will  be on them.

However, there are some organizations that choose to jumpstart their agile transformation by allowing team members to decide which teams they want to work on, rather than having managers assign them to teams. It is about empowerment and decision-making and allowing team members to make those decisions.

I have had the privilege of facilitating team self-formation exercises at two different organizations. Team self-formation is when the individual team members are allowed to choose which team they want to work on. This is commonly done through providing descriptions of the team vision and backlogs of work that are needed, and the number of teams desired and then letting the individual team members decide how to form teams.

Ahmad Fahmy wrote a great article about this type of exercise at Bank of America. Ben Kopel wrote an article about a similar exercise at Chicago startup Uptake though he called it self-selection teamification. Which probably didn’t clear up any confusion.

Isn’t this Anarchy? Who is In Charge?

Some people think that self-organization is the same as anarchy. They don’t believe that people will actually do the right thing, or what is expected of them if the context is correct.

More traditional leaders will expect to have a single throat to choke, rather than want to deal with an entire team.

It has been my experience that this never happens. Teams are given guide rails to run on. The priorities are set by the product owner. The team members are usually chosen by leadership, who will usually also set the agile framework to be used (such as Scrum or Kanban). It’s not anarchy.