Press "Enter" to skip to content

Self-Organising Teams

First published in Langerman Panta Rhei

In our Modern IT Management Lecture series, we discussed Agile and Scrum frameworks in significant depth. An important part of these frameworks is the creation of self-organising teams. In order to adopt self-organisation, the traditional approach that involves the top down management of professionals and low levels of autonomy must be excluded. Rather, the adoption of self-organising teams for Agile software development should be pushed forward because it increase team autonomy, and thus, increases motivation and productivity and benefiting the organisation overall. In this lecture, we will define self-organising teams, discuss the roles within them, explore the various levels of autonomy, and address the barriers that hinder the success of self-organising teams in Agile software development.

Self-organising Teams

Self-organising teams have been defined as:
“…being composed of individuals who manage their own workload, shift work among themselves based on need and best fit, and participate in team decision making.”

Characteristics that set self-organising teams apart from others is their maintenance of both team autonomy and individual autonomy. The individuals who form part of this team have been identified according to the reliance of their jobs on each other. These teams are given substantial authority and control over their own work, planning, task assignment, and important decision-making. Naturally, this increases autonomy in the group, boosting morale, increasing participation, and contributing positively to overall team effectiveness. As a result, the organisation benefits and its probability of success increases. Along with this, giving individuals closer to the level of operations more authority and responsibility improves problem solving accuracy and speed because those who are closest to the area in need of attention are the ones who make the decisions with regards to how to move forward. The need to filter information through to higher powers to decide how to problem solve is made null, saving time and resources.

It is important to note, however, that these teams, although self-organised, cannot be allowed to become uncontrolled. Uncontrollable self-organised teams become a detriment to the organisation because they can cause instability, ambiguity, and tension which will eventually lead to chaos within the teams and, in turn, the organisation. Organisational management must be tasked with ensuring that this does not happen. Despite allowing the self-organised team to maintain its autonomy, outside management of the teams must remain present at some level to avoid dysfunction but still ensure that they do not employ inflexible control regimes that might hinder the creativity, spontaneity, and overall success of the teams. This is a very delicate and important balance that must be maintained so that optimal success can be achieved within the teams and organisation. Any imbalance risks creating a hostile environment that is not beneficial for teams or the overall organisation.

This balance is depicted in the image below.

Research done shows that the success of self-organised teams is extremely situational, indicating a high variance and not as much consistency as the theory behind the creation of these teams may suggest. Consequently, it has been noticed that the type of autonomy within and outside of these teams is extremely important. This must be a point of focus as well, not just the amount of autonomy.

Levels of Autonomy

Autonomy has been defined as:
“…the degree to which the task provides substantial freedom, independence, and discretion in scheduling the work, and in determining the procedures to be used in carrying it out.”

Due to the variance in success of self-organising teams, the level of autonomy afforded to the teams by the organisation’s management must be heavily considered. The varying levels of autonomy – including exterior, internal, and individual – and their pros and cons must be weighed. In this way, managerial practices can ensure that the correct balance of autonomy and control is maintained. These levels and their pros and cons are showed below.

Self-Organising Team Roles

In order to facilitate team self-organisation, individuals take on one or more of the 6 identified roles found within a team. These are:

  1. Mentor: provides support and guidance for the team, ensures that they become confident in the use of their Agile methods, and encourages consistent use of Agile practices.
  2. Co-ordinator: represents the self-organised team in order to facilitate communication and change requests from the customers.
  3. Translator: improves the communication between the customers and team by translating the language used by the customer and the technical language used by the team.
  4. Champion: communicates with senior management within the organisation. This ensures that support is gained for the self-organisation of the team.
  5. Promoter: ensure collaboration of customers with the team. This ensures that optimised functioning of the self-organised team is supported.
  6. Terminator: involves senior management when detrimental team members are identified that may decrease the productivity and functioning of the team and ensures that they are removed.

The various roles and their collaborations are indicated in the diagram below.

Obstacles to introducing self-organising teams

The most prevalent obstacles studies have found that have to be dealt with when creating self-organising teams included the strategic division of work within the team according to highly specialised skillsets. The same research shows that this was motivated by traditional, bureaucratic, and often correct assumptions such as:

  • Resources will be wasted if multiple people are working on the same project.
  • Work cannot overlap in the project currently being handled due to time constraints.
  • The tasks for the project must be delegated and solved effectively today.

Whilst these assumptions do eliminate the possibility of redundancy, which is traditionally desirable, it does not take into consideration the complexity of the tasks that must be handled by self-organised teams. Contrary to tradition, the creation of self-organising teams requires some form of redundancy as a prerequisite. Specific redundancies benefit the team by allowing each member to obtain multiple skills, allowing them to complete each other’s jobs and act as substitutes if required. This ensures that self-organised teams develop their characteristic flexibility, improving the efficiency of the team, and benefitting the organisation. Additionally, it improves mechanism of change adaptation and creates a backup system for the team. Together, these aspects increase the internal autonomy of the team. Without this redundancy, flexibility within self-organised teams and the organisation is lost, thus, the organisation is negatively impacted. In order to successfully implement self-organisation within Agile or Scrum, these factors need to be considered.


Self-organising teams can be of extreme benefit to an organisation because of increases in the autonomy of the team and its individuals. By doing this, these individuals are more motivated to achieve the goals of the business and become more productive and efficient. In the long-term, this will greatly benefit the organisation and contribute to its ability to adapt to change, cultural improvement, and overall success. Nevertheless, success using these teams is variable emphasising the need to ensure that the barriers to producing and adopting these teams are overcome. Additionally, the level of autonomy given to this teams my outside management must be evaluated. Once this is done effectively, the teams will contribute positively to the overall organisational structure, culture, and its success.


Hoda, R., Noble, J. & Marshall, S., 2010. Organising Self-organising Teams.
Moe, N. B., Dingsoyr, T. & Dyba, T., 2008. Understanding Self-organising teams in Agile Software Development19th Australian Conference on Software Engineering, pp. 76-83.

Share on...

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *