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:
- 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).
- 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.
- Team Size – Define the maximum and minimum number of people on a team. See: Scrum Team Size
- 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:
- Orientation – Before the event, explain how self-selection works and why it’s being adopted.
- Process Visualization – Draw a simple picture visualizing the day’s activities.
- Shared Constraints and Product Vision(s) – Share the predefined constraints, product visions, and the product owner for each team.
- Team Selection – Individuals choose their teams based on product vision, skill demand, and who else they want to work with.
- Team Assessment – After each selection round, review the teams for imbalances or constraint violations.
- 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.
Resource Links:
- A Practical Look Into Self-Selecting, Distributed Teams
- Empowering self-organising teams with self-selection
- How to Form Teams? A Story of Self-Designing Teams
- How Self-Selection Lets People Excel (Sandy Mamoli and David Mole)
- Self Selecting Teams (Sandy Mamoli and David Mole)
- Self-Selecting Teams: Could It Work For You?
- Self-Selecting teams – tales from WW2 Lancaster bomber crews
- Teamification: Agile Team Self-Selection
- Team Self Selection Pocket Guide (Sandy Mamoli and David Mole)
- Team self-selection (without the anxiety)
- Team Self Selection workshop
Research
- High-performing teams and the case for self-selection
- (PDF) Agile Self-selecting Teams Foster Expertise Coordination
Books
- Creating Great Teams: How Self-Selection Lets People Excel by Sandy Mamoli and David Mole
See Also:
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.« Back to Glossary Index