People seem to be easily confused about the concept of self-organizing teams. They confuse it with self-forming, self-directed and self-managing. What do all these terms mean? Are they all the same or do they mean different things?
What are Self-Organizing Teams?
Let’s start with 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 organizing 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 Guides, 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, The Wisdom of Teams. Hackman looks at 4 different factors for team oversight and management including who provide the direction, who designs the team, 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 a team self-formation exercise (and will do so again shortly for a client). Team self-formation is when the individual team members figure out who should be on which teams. This is commonly done through providing descriptions of the 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 relate the idea self-organizing to anarchy. They don’t believe that without limits that people will actually do the right thing, or what is expected of them.
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.