Self-Selecting Teams

The default assumption when creating a new team is that the management and team leads will do the selecting and organizing. (Wait, team leads… are they even part of Scrum?) When a team is formed this way and then members are told that they have autonomy and they can self-organize, there is a bit of a dichotomy.

A true team is built on the strength of the team members’ relationships. When management creates a team, it starts with weaker relationships, and often initial competition and conflict. Collaborative relationships may build up successfully over time, or they may not.

When people are given the opportunity to form self-selecting teams, we gain a real benefit because relationship bonds are already in place, and the team environment causes them to strengthen further.

The Power of Autonomy and Reducing Resistance

Autonomy is at the centre of all the human motivational models we recommend: SCARF, ARC, AMP. Self -selection gives team members more of their autonomy back.

When team members choose their teams, they naturally align with roles and projects that complement their competencies and interests. This liberty doesn’t just create a dynamic work environment, but it also breeds motivation and engagement, driving innovation and productivity.

Self-selecting teams also reduce resistance to change. Team members can say, “I made a choice to be part of this team,” so, when things get difficult, it gives them an incentive to make the team work.

Setting Boundaries for Effective Self-Selection

Self-organization requires constraints or boundaries to be effective. Self-selecting teams need:

1. Team Competence - The Scrum Team should be cross-functional (i.e. the team is able to deliver complete user stories or features, without asking another team for help).
2. Skills - For example, one front-end developer, one backend developer, one additional developer, one tester, and someone with requirements or UX knowledge. Clearly this will vary as it depends on the project needs. Note, not everyone makes this an explicit constraint.
3. Team Size - Define the maximum and minimum number of people on a team. See: Scrum Team Size
4. Stewardship - Individuals should make choices on what they believe is best for the organization/product.

Sidebar: If the product being built requires few people (3 or less), consider making it part of the work of a bigger team. The same happens if the product work will be short-lived. Form high-function teams and then keep them fed. Unless truly required, don’t pay a team re-formation tax every few months.

Mechanics of Self-Selection Process

The self-selection process involves several steps:

1. Orientation - Before the event, explain how self-selection works and why it’s being adopted.
2. Process Visualization - Draw a simple picture visualizing the day’s activities.
3. Shared Constraints and Product Vision(s) - Share the predefined constraints, product visions, and the product owner for each team.
4. Team Selection - Individuals choose their teams based on product vision, skill demand, and who else they want to work with.
5. Team Assessment - After each selection round, review the teams for imbalances or constraint violations.
6. Iterative Rounds - Usually, after three rounds, teams settle down.

From start to finish these events can take from two to six hours to run. The determining factor is the number of people in the group.

Stalemates and Logjams

After three rounds of self-selection, most groups are satisfied with the results.

If problems remain, there a couple of options. Sometimes a good conversation around why things are stuck can help. Amber Field has an example:  “Our Engineering Director started a conversation, discussing everyone’s motivations for being on the over-staffed team (people loved that it was a full-stack team, they wanted to work with the leads, they wanted to do front-end work, etc). After one of our engineers spoke about wanting to work on a front-end solution that we call the Monitoring Dashboard, one of our Agile Program Managers realized that if we moved the Monitoring Dashboard work to one of the open teams, 1–2 engineers would happily come with it. After several sidebars, the matter was decided. The stalemate was over, we had our teams filled, and the event ended 30 minutes ahead of schedule!”

In another example I know, leadership gave the group a choice: either they self-organize to solve, or leaders can step in and make a decision for them. While forced decisions are risky, it seems to have paid off in that case.

How Do People Choose

Some make their selections based on interest in the product vision, and others choose because they already know some of the people on the team. In fact, many people move in groups of twos and threes, which tells us that the benefit of the latter is that they already know they get along with some of their teammates, which helps speed the team formation process.

Potential Fears and Risks

The self-selecting process in teams isn’t without risks. A lack of a clear product vision can make it harder for teams to understand what they’re organizing towards. Similarly, if there’s a lack of trust or an environment of fear, it hampers effective self-organization. If either of these are at play, they will likely need to be addressed before running a self-selection exercise.

Convincing Management

To convince management about the merits of self-selection, it’s crucial to address business constraints and present potential scenarios, as Serena Caruso mentions in an interview. “Even in the ‘worst case scenario,’ where agreement isn’t reached, the organization gains insights into team preferences and dynamics, shedding light on the complexity of team creation and the potential need for a top-down approach.” These insights wouldn’t have been gleaned in a traditional approach.