What does it mean to say an agile team is self-organizing? And is that even the right term? Some people say teams are self-managing. To understand which of those terms might be better, let’s consider four levels of authority teams can assume.
Four Ways of Distributing Authority
Richard Hackman, a Harvard University professor, described four levels of allocating authority to teams. Let’s look at Hackman’s four levels of team authority starting with teams with the least authority.
Teams with the least authority are manager-led teams. A manager-led team has authority for performing the work it has been assigned. But a manager-led team does not have authority over its process. That remains with the team’s manager.
Next are what Hackman referred to as self-managing teams. In addition to performing the tasks, a self-managing team manages its own process. A self-managing team can decide how it will work. It could, for example, decide to use (or not) an agile approach.
Increasing authority is given to self-designing teams. A self-designing team is given the additional authority to modify who is on the team. This type of team can kick a person off the team, can decide to hire or transfer an additional person onto the team, and so on. In some cases a self-designing team will also be given authority over reporting relationships both within the team and to those outside it.
The final type of team, and the one with the most authority, is a self-governing team. A self-governing team is given the additional authority to change the team’s main purpose. A self-governing team could decide to build the video game instead of the acoustic measurement product.
The four types of teams are summarized in the following table.
Type of Teams | Authority |
---|---|
Manager-Led | Authority only for performing the work |
Self-Managing & |
Also has authority over how work is done (the team’s process) |
Self-Designing | Also has authority over who is on the team and sometimes over reporting relationships |
Self-Governing | Also has the authority to alter a team’s main purpose |
These four types of teams and the authority given to each are also shown in this diagram.
Where Does Self-Organizing Fit?
In Hackman’s authority hierarchy, self-organizing agile teams would be classified as self-managing teams. Agile teams manage their own work (which team member should do this task?) and how they go about that work (should we start with Kanban or Scrum? How long should our sprints be?). Agile teams are not, however, self-designing or self-governing. In other words, a self-organizing agile team has authority over its work and the process it uses, but not over who is on the team or the team’s purpose.
So Is It Self-Organizing or Self-Managing?
You can call it either one. My personal preference is for self-organizing for two reasons:
First, that is how it was described in the first published article on Scrum, the oldest agile framework. The authors of that paper, Takeuchi and Nonaka, considered self-organization to be one of the six characteristics needed to create a “fast flexible process.”
Second, I find the origins of the term self-organizing in chaos theory useful in thinking about team behavior. The flocking of birds in flight is self-organizing behavior. So is an ant colony, a beehive, or the pattern of cars on a highway. These examples of self-organization in nature often provide useful, illustrative examples for what self-organizing may mean to an agile team.
For example, living as I do in Colorado, I often see prairie dog “towns,” collections of tunnels these small animals dig. Prairie dogs don’t dig their tunnels according to some preconceived master plan. They dig and if they hit a rock they dig around it. A team starts in a direction. If that direction proves untenable, the team alters course around the obstacle, just like those prairie dogs.
So, self-organizing is my preference due to its history in the agile literature and the usefulness of examples of self-organization. But self-managing is equally good if you prefer it.