en
de

3 Conditions influencing Self-Organization of Teams

30 July 2014
| |
Reading time: 5 minutes

Self-organizing teams are one of the major trends in today’s work environment. The increasing pervasiveness of agile methodologies fuels this trend as most of them rely on self-organizing teams as a cornerstone of their collaboration approach. It is important, however, to note that self-organization is a principle that is not tied exclusively to agile methodologies, let alone was invented as part of one of those methodologies.

If you take a look at any development team, the question is not whether the team is self-organizing or not, but rather the degree of self-organization in the team. Even in the most rigidly hierarchical and process oriented environments the team members still have to act autonomously, communicate and make joint decisions regarding their daily work. Software development is just not comparable to an assembly line, where almost every hand movement is predetermined for you. Unfortunately some organizations had to learn this the hard way.

The following famous quote, apart from proving that self-organization was known of before agile methodologies, hints at why a high degree of self-organization is preferable.

“If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea. As for the future, your task is not to foresee it, but to enable it. ”

Antoine de Saint-Exupéry (The wisdom of the sands – 1948)

It simply is the case that a team working towards a desirable goal and having extensive autonomy to arrange the work as it sees fit, tends to be more motivated and thus be more efficient and effective in reaching its goal. This is especially valid for complex tasks and a highly qualified team. Both conditions typically apply to software development projects. At the same time the team members experience a higher degree of satisfaction with their work, which is a very important aspect if you are looking to retain the best people on the team.

So does that mean that if you, the project- or line manager, want the team to do something for you, it is sufficient to make the team yearn for something and then leave them to it, as you might deduce from the above quote? No!

If you drum up a bunch of software developers from different countries in the middle of the Sahara and teach them to yearn for the vast and endless sea, it might take a while before you will be able to set sail. And frankly I would rather not be on that boat. You have to create the best possible conditions for the team to thrive and reach its goals. All this must happen with as little restriction on the self-organization of the team as possible. The tricky thing obviously is to identify those conditions that should be optimized.

During a recent assignment coaching an organization through a transition to scrum I’ve stumbled upon the CDE model proposed by Glenda Eoyang in her dissertation (PDF) and mentioned by Mike Cohn in his book “Succeeding with Agile”, which I think provides an interesting approach to systematically analyze the situation of a team and its surrounding conditions. It proposes the following three categories of conditions that influence self-organization in a team:

  • Containers
  • Differences
  • Exchanges

Container: “Any bounding condition that distinguishes a system from its environment” (e.g. room, office site, department, project, company, profession, nationality, religion, culture)

Difference: “A distinction within a system that establishes a potentially generative tension, which represents the potential for change” (e.g. experience, knowledge, power, skills)

Exchange: “A transfer of information, resources, or energy between or among system agents that results in changes within the agents and/or changes in system-wide patterns” (e.g. conversation, meetings, e-mail communication, observation)

The goal is to identify the containers, differences and exchanges that significantly influence the performance of the team and adjust them if necessary. The complicated part is that there are a myriad of coexisting containers, differences and exchanges influencing the team and each other. Because of these interdependencies the consequences of adjustments to complex systems a.k.a. teams can never be predicted with complete certainty.

So how can we utilize the CDE model to analyze and improve the conditions for self-organization? The most intuitive approach is to start with a problem and examine how the existing containers, differences and exchanges contribute to the problem. Let’s try this with a not too fictional scenario.

Two teams are developing two applications A and B. Application A has to provide data to application B in the form of multiple files exported and imported automatically on a nightly basis. This process fails regularly due to changes applied to either one of the applications without considering the consequences on the interface.

  • Containers: The central container to consider in this scenario is the system consisting of the two applications connected by the interface. The separation in two teams establishes the teams as separate containers with different goals within the central container. If the two teams belong to different departments this separation is further amplified. The maintenance of the interface should be made a central goal and responsibility of both teams. A bigger issue would be conflicting department goals, which would indicate failed alignment with company goals. If both teams work at different locations or even in different countries, those differentiators would also be separate containers that hinder communication. Since co-location of both teams will probably not be an option in most cases, this issue can be addressed by establishing additional exchanges to foster communication.
  • Differences: The developers on both teams are not aware of, or have different perceptions about the interface between the applications. Because of this they cannot foresee the consequences of code changes on the interface. The teams should be educated about the interface and the factors that influence it in both applications. In general differences are not necessarily a bad thing. Different perspectives or skills can help the team to achieve its goals. In this case however the described differences have negative effects and should be minimized.
  • Exchanges: The existing exchanges obviously do not fulfill the goal of ensuring that the team members are aware of the interface requirements. If it doesn’t exist yet, a description of the interface should be created and made available to both teams. This exchange provides a reference to look up the interface details and its requirements. The description needs to be maintained and agreed upon by both teams, triggering communication and notifications in case of modifications.

Now, you might ask, is that still self-organization? After all, you are introducing additional constraints. Yes, but as I have mentioned at the beginning of the article self-organization is not something that is either there or not. It is the ideal level of self-organization that varies between teams.

With another team setup this problem might not even exist, because there happen to be individuals on both teams, who never forget to think about the potential impact of changes on an interface. Starting with a set of minimum constraints depending on the team setup and the project context and adjusting this set of conditions is therefore a natural way to let the team self-organize around those constraints and hopefully approximate the ideal level of self-organization.

What is the benefit of the CDE model for this evolutionary approach? First of all, it provides us with a tool to think more methodically about self-organization of teams. Yes, you can arrive at the same conclusions and derive the same optimization measures based solely on personal experience and intuition, but you are more vulnerable to biases and blind spots.

Furthermore it establishes a common structure and terminology, which is useful for communication. Given that it is sufficiently abstract, it can be utilized at various organizational levels and is applicable to every type of team, which operates with a significant degree of self-organization.

Comments (0)

×

Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.