Limits of a Self Organizing Team

The idea of a self-organizing team has been promoted strongly since the Agile movement started to gain popularity following the publication of the Agile Manifesto in 2001. The list of principles that support the four tenets of the Manifesto includes a brief mention of the idea: “The best architectures, requirements, and designs emerge from self-organizing teams.”

It’s noteworthy that there is no definition of “best,” nor of “self-organizing teams,” in the document. In fairness to its authors, however, we should remember that the definition of manifesto is “a written statement declaring publicly the intentions, motives, or views of its issuer,” according to Merriam-Webster. So, it isn’t strictly necessary for the authors of a manifesto to define terms or express things precisely. By definition, a manifesto is a subjective expression of general views.

Clearly, one of the general views of the authors of the Agile Manifesto is that self-organizing teams tend to produce good results. Okay, then: What do we mean by self-organizing team?

What is a Self-Organizing Team?

I’ve touched on the subject in the past in a light-hearted way, in two complementary posts, The micromanager’s guide to self-organizing teams, and The self-organizing team’s guide to micromanagers. Let’s take a slightly more serious look at the question.

It’s not easy to find a clear and generally-agreed definition of self-organizing team. People tend to leap directly to topics like “how to lead a self-organizing team” or “how to form/grow/coach a self-organizing team” or “misconceptions about self-organizing teams” without actually defining the term.

In an article in Forbes, Steffan Surdek offers three key characteristics (paraphrased here):

• has a certain level of decision-making authority
• is working toward meeting their emerging vision
• takes ownership of how they work and continuously evolves

Okay, that’s a start. But what is “a certain level?” And aren’t all teams working toward meeting their emerging vision, whether self-organized or not? And aren’t “takes ownership of how they work” and “continuously evolves” two different things? If they “own” how they work, then isn’t it up to them whether to “evolve?” The purpose of that article is to discuss misconceptions about self-organizing teams, and yet it begins with a rather shaky definition of the term. Let’s keep looking.

The Scrum Alliance, an organization that supports an Agile-aligned method known as Scrum, offers an explanation of self-organizing teams, written by Nitin Mittal. Paraphrasing some of the key points about self-organizing teams from that piece:

• They pull work for themselves
• They manage their work
• They don’t require “command and control”
• They communicate more with each other than with their ScrumMaster
• They aren’t afraid to ask questions
• They continuously enhance their own skills

A common theme about continuous improvement seems to be emerging. We’ll soon see that the original idea of self-organizing teams doesn’t include that point. But ultimately we’ll see how the idea ties back to self-organizing teams in the context of Agile software development.

Here we have the notion that a self-organizing team manages its own work — deciding which work items to pull rather than awaiting assignment by a manager or team lead; deciding who on the team will work on which items; communicating with each other more than with a team lead; openly asking questions to clarify their understanding. This gives us a clue about what Surdek may have intended when he wrote, “a certain level of decision-making authority.” Is this the “level?”

Mike Cohn, a respected thought leader in the Agile community, attempts to clarify the meaning of “self-organizing team” in his article, The Role of Leaders on a Self-Organizing Team. He writes, “Self-organizing teams are not free from management control. Management chooses for them what product to build or often chooses who will work on their project, but they are nonetheless self-organizing. Neither are they free from influence.”

Further clarifying this point, Cohn quotes the 1986 article by Takeuchi and Nonaka, “The New New Product Development Game,” in which they wrote, “subtle control is also consistent with the self-organizing character of project teams.” He also quotes from The Biology of Business by Philip Anderson: “Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.”

Now we’re getting somewhere. Clearly, the authors of the Agile Manifesto didn’t make up the term out of thin air. It was already a “known thing,” at least in some circles. Once released into the wild, however, the definition of self-organizing team seems to have drifted.

What is a Self-Organizing Team Not?

The pre-Agile definition doesn’t appear to have included anything about continuous improvement. It seems to focus on allowing teams to figure out the best way to get their work done. Nothing more. There’s nothing about self-management, for instance. Team members still have managers. These teams don’t handle their own human resources issues or their own financials. They don’t decide what the organization should build; they just build it.

There are those in the Agile community who insist the role of the manager is obsolete. An organization built around self-organizing teams has no need of the management function at all. They call not only for self-organizing teams, but for self-managing teams.

I’m unconvinced.

There’s a commonplace among agilists these days that a development team needs to understand, and even to participate in the definition of the business value of the software they are building or supporting. I will suggest this is not necessarily true. In a very small organization, it’s possible for development team members to be aware of and even to participate in the elaboration of “customer value.”

In larger organizations, however, development teams are so far removed from the strategic planning of the enterprise that their understanding of “value” can never be anything more than whatever their key stakeholders tell them it is. In addition, very few people who work at the hands-on level possess the skills necessary to carry out business analysis and planning at the enterprise level. Even if they were invited to the table, they would have relatively little to contribute.

I can imagine some software engineers taking umbrage at that comment. After all, they are so smart that they can figure out anything, right? And there are plenty of Agile coaches who like to say companies are “dysfunctional,” despite their 10 billion dollar a year operations. But history has not been kind to the concept of workers controlling the means of production.

The twentieth century saw a number of attempts at real self-management. These ranged from union-organized cooperatives in Germany to cooperatives in the Pacific northwest timber industry in the US to the steel industry in the eastern US to the only genuine attempts (maybe) at Communist-style worker ownership in the former Yugoslavia. The only one that has succeeded in growing and sustaining itself is the Mondragon cooperative in the Basque region of Spain, which has some unique characteristics compared to other examples.

The bottom line appears to be that those who understand how to get the work done in the best way may not be equally well-suited to running the company. Actually, there’s an excellent chance they’re not.

Thus, the original idea that a self-organizing team can take ownership of how the work is done makes sense, while the idea that they can also help to define business value does not make sense in all circumstances. That said, it’s been my experience that when we understand the value of our work to customers, we tend to feel more dedication and movitation, and greater satisfaction upon achieving a goal, than when we are merely carrying out assigned tasks with no context. It is helpful for a self-organizing team to be included in discussions of customer value, even if the individual team members have little to contribute to such discussions.

Natural Boundaries of Self-Organization

Something fundamental is missing from all these various definitions and explanations: What does it mean to self-organize?

If we accept that self-organization means a team determines how best to carry out the work, then what are the boundaries of the decisions the team can make?

Will the team employ pair programming or mob programming? Yes, that’s in scope. Will the team use test-driven development? Yes, that’s in scope. Will the team work five eight-hour days, four ten-hour days, or use some other arrangement for work hours? Yes, that’s in scope. Will the team perform exploratory testing together on a regular basis? Yes, that’s in scope. Will the team members teach one another their various skill sets while completing work items? Yes, that’s in scope. Can team members work remotely? Yes, that’s in scope. Will the remediation of technical debt be considered part of the team’s definition of done for work items? Yes, that’s in scope. Will the team apply the concept of continuous improvement? Yes, that’s in scope.

Will the team members receive a bonus? No, that’s not in scope. Will the team determine which strategic initiatives are likely to yield a positive return on investment for the corporation? No, that’s not in scope. Will the team define the organization’s policies with regard to discrimination or harassment? No, that’s not in scope. Will the team decide which market segments the company ought to focus on? No, that’s not in scope. Will the team decide that they are eligible for additional vacation time beyond the organizational standard? No, that’s not in scope. Will the team decide that this particular team member should be fired from the company? No, that’s not in scope.

Will the team decide whether this particular job candidate is hired and placed on the team? That may be in scope. Will the team decide that this particular team member should be removed form the team? That may be in scope. Will the team define their own dress code? That may be in scope. Will the team decide which continuous integration server to use? That may be in scope. Will the team have full control of test environments and deployment activities? That may be in scope.

Anything that pertains directly to how the work is done is in scope for a self-organizing team to decide, unless there are organizational considerations that trump their decision. For instance, an autonomous team in a small organization can and should choose its own toolchain for continuous delivery, while a team in a larger enterprise may be constrained to use the toolchain that has been selected for the organization, for consistency in operations.

Some additional matters may be in scope for self-organizing team depending on context. For instance, if the team feels the organization’s formal anti-harassment guidelines are too loose, they could craft a team agreement that defines tighter guidelines for their own use; but they could never do the reverse of that, and loosen organizational anti-harassment guidelines for themselves.

The same rule of thumb applies to technical practices, as well. An organization may publish a guideline to the effect, “We encourage teams to use test-driven development when feasible.” A self-organizing team has the right to include a statement in their team agreement to the effect, “Our team will use test-driven development as a baseline technical practice.” However, they don’t have the right to say, “Our team categorically refuses to use test-driven development.” A self-organizing team can tighten, but not loosen, organizational guidelines for themselves.

Self-Organization, Self-Management, and Self-Assembly

I once coached a team that wanted to push the boundaries of self-organization. Bit by bit, they took on increasing responsibility for their own work. At one point, most of the team members felt that a certain colleague was not pulling his weight. They asked their administrative manager if they could take ownership of that situation, too. She said yes.

She and I discussed the matter and agreed that the team was not going to enjoy what was about to happen. We also agreed it would be important and useful for them to experience it.

The team devoted a retrospective to the question of that colleague. Collaborating with him, they crafted an improvement plan for him to follow, and he agreed to it. They gave him six weeks to get aligned and up to speed. Four weeks later, he gave his two week notice and left the company.

The team decided they never again wanted to deal with a human resources issue. They had discovered their own limits. They embraced self-organization whole-heartedly and effectively. When it came to self-management, they learned that they did not wish to “own” it.

For me there’s a lesson here: You don’t really know what your limits are until you exceed them. Then you know you want to step back a bit. So, go ahead and exceed your limits. It will be uncomfortable, but it won’t be the end of the world, and you will have learned something valuable that cannot be learned in any other way.

At the other end of the scale, there are teams that never rise to the level of self-organization in a meaningful sense. They sit together, they work together, they pull work, and all that good stuff. But they never truly self-organize.

The Swiss consultant Joseph Pelrine considers a spectrum of team organization that spans self-assembly, self-organization, and self-management. The team I mentioned above dipped their collective toe into self-management waters and didn’t like it. Pelrine notes that many teams never even reach the level of self-organization.

In 2013 I described a conference session Pelrine facilitated in which we explored this concept in 2009. Unfortunately, I don’t know of another more direct source of information about the concept. In any case, the idea is that people can self-assemble on the fly when necessary, but such assembly only becomes self-organization when it results in some lasting change in behavior.

Pelrine used the situation of riding an elevator to exemplify. We made a square on the floor out of painter’s tape and pretended it was an elevator. As the elevator stopped on various floors, participants in the session got on and off.

In the debrief, Pelrine called attention to the fact that people automatically shifted position to allow others to get on the elevator, or to make space for riders to get off when the elevator reached their floor. He called this self-assembly.

People made adjustments to allow a task to get done, but they did not form working relationships or modify their general practices as a result. For those reasons, self-assembly was insufficient for self-organization.

So it is, too, with teams. You can put people in a work space together and call them a team, but if team formation doesn’t occur and the way people work doesn’t change, then the result isn’t self-organization. This ties back to the Agile notion that a self-organizing team “evolves” or “continuously improves.” Lacking this sort of progressive change, what we’re looking at is merely self-assembly.

Conclusion

Some general observations about team self-organization emerge from this exploration:

• Putting people together in an elevator or a work space doesn’t make them a team
• Telling people they are a self-organizing team doesn’t make them one
• Self-organization is not the same as self-management
• Teams can own the ways in which they carry out their work, but they don’t define what the work must be
• If working together doesn’t result in relationships and behavioral change, the work group is not a team
• Teams can define stricter rules for themselves than the organization requires, but they can’t loosen the organization’s rules as applied to themselves