Allowing people to form their own teams, through team self-selection, can be a powerful approach to promote empowerment and to form viable teams with fast transition towards high performance. However, if the process is not carefully facilitated, team self-selection may lead to dysfunctional teams and disgruntled team-members. We have tried both outcomes and based on our experience we have identified patterns that lead to success – or failure. Our experiences are based on applying team self-selection in a SAFe-organization.
1. INTRODUCTION
At the very heart of Agile there is a strong belief that teams are best suited for solving complex problems. However, when it comes to the formation of self-organizing teams many agile organizations revert to more traditional management approaches where one or more managers decide on the team compositions. This seems paradoxical since most people would acknowledge that formation of viable self-organizing teams from a pool of people is a highly complex problem to solve. Furthermore, for an organization to be truly agile, empowerment of the employees is crucial. Yet, truly empowered employees are not something that can be dictated by management, it will only occur if the employees feel that they are genuinely empowered, in other words management must walk the talk. This is particularly important for organizations transitioning from a command-and-control culture to an empowerment culture. But how can management successfully promote empowerment when they at same time do not trust people to form their own teams?
Sometimes management resistance towards team self-selection is rooted in middle managers fear of losing, power, prestige and influence, but there are also many relevant less selfish concerns. For instance, how do we ensure diversity in teams? Or how to ensure a balanced mixed of junior as seniors. Or how to prevent the process from turning in to pseudo reality show where some people are being “voted of the island”? To be more general; how to ensure that the process leads to team compositions that are aligned with the organization’s strategies and values?
In this paper we will show how team self-selection, if carefully facilitated, can overcome these concerns and be a powerful approach to promote empowerment and to form viable teams with fast transition towards high performance. The book, Creating Great Teams: How Self-Selection Lets People Excel, by Mamoli and Mole (Mamoli & Mole) served as inspiration for us.
In the following we will describe the steps in our team self-selection process and our experience with the process in practice. We will share our success and failures and describe the patterns we have found that creates the foundation that can lead to high performing teams and the patterns that may lead to dysfunctional teams and disgruntled employees.
2. BACKGROUND
In 2016 SimCorp’s Product Division kick-started our agile transformation by implementing SAFe for more than 550 people forming more than 55 teams within 7 ARTs all working on the same product. Coming from a traditional line organization, the implementation of SAFe meant that departments were split into several component teams distributed in the various ARTs.
As part of the new agile mindset, management encouraged experimentation throughout the product division. With this new freedom we seized the opportunity to tryout team self-selection.
2.1 The team self-selection model
Our team self-selection model is based on the work described by Mamoli & Mole. In brief the process consists of three distinct parts centered around the main event, the team self-selection workshop. The first part is preparation (1). Then the workshop (2) itself, and finally follow-up (3) including getting feedback from the newly formed teams.
- Prepare
Before the workshop, the teams’ purpose and mission must be clarified including business objectives, technical challenges and expected lifespan of the teams. All of this is needed to establish the guiding principles, which defines the constraints of the team self-selection process and prescribes what the teams are being optimized for. Examples of a guiding principle could be distribution of competences, domain knowledge within the teams, and location.
To help building transparency regarding domain knowledge and competences within the group, it is our recommendation that the group co-creates a skill/desire matrix. In this matrix each person indicates her interest level in a given domain or skill ranging from e.g. “I’m super-passionate about this!” to “Totally uninterested. I don’t want to work with this or learn anything about it!” For the same set of domains and skills individuals rank their competence level from “Beginner: Mainly theoretical knowledge about subject matter with little practical experience. Need ongoing coaching and supervision to complete basic tasks.” to “Master: Is recognized outside our company as a leading authority within the subject matter. Creates theory and/or defines best-practice.” This matrix should be an open document and co-created prior to the event. To create more clarity over skills and work interests, we have also found it beneficial to create personal cards showing each person’s interests and competences (see later) to be used in the team self-selection process. These cards are particularly useful for larger groups or for groups where people do not know each other well.
- The workshop
At the workshop, after being introduced to purpose and mission as well as the specific guiding principles, people self-select a team in an iterative approach (see Figure 1). Within a predefined interval (e.g. 10 minutes) participants are free to move from one team to another as often as they want taking own preferences and the guiding principles into consideration (step 1). When the first period ends or when team formation appears to have stabilized, each of the newly formed teams discuss how well the team complies with the guiding principles. (step 2). Then in step 3, each team presents their findings to the entire group, and potentially raise any concerns they may have regarding some of the other teams. Step 4 is a converging check to evaluate whether another iteration is needed or whether a timeout is required. Time-outs may be needed if the teams have not changed since the last round, but are not compliant with the guiding principles either, or if the process appears to have no prospects of convergence. If the group decides that another iteration could be beneficial, they remove all evidence of the previous selection (step 5) and start all over again. Time-outs may be used to identify and address root causes of non-convergence of the process, and ultimately to decide whether to cancel or halt the workshop until root causes have been addressed.
Each individual participating in the team self-selection carries a personal card. Besides name and photo, the card may also list competences or other relevant information e.g. location. On a wall or whiteboard in the room where the team self-selection takes place, a team slot is created for each of the new teams to be created plus one. The extra slot may be marked with a question mark or similar and is to be used if a person cannot decide which team to join. Team names should be blank to avoid any biases related to temporary team names, e.g. “Team 1” may sound more appealing to than “Team 2”.
The model described above is very similar to the model proposed by Mamoli and Mole with a couple of exceptions. First, we start every iteration from scratch with everybody participating including those who have already formed viable teams, whereas in Mamoli and Mole’s model people do not participate in subsequent iterations if they have formed a viable team. Second, we have included an “undecided” option, which allows people to postpone their choice until a later iteration.
- Follow-up
After the team formation, traditional team building activities can be performed e.g. naming of the teams and team working agreements. However, special attention should be given to follow up on any issues that may have surfaced during the workshop; for instance, hidden conflicts, hurt feelings or aversions within the group.
Figure 1: Iterative team self-selection process diagram developed by us.
3. OUR JOURNEY
In the following sections we will go through 5 different cases of team self-selection. We will describe the different learnings we have gained from different real-life situations.
3.1 Case 1: Forming three feature teams out of two component teams (18 persons)
Since this event took place in the very beginning of our agile journey, we realized, that we had failed in communicating “why” we wanted cross-functional teams, and the team formation was converging towards teams very similar to the existing component teams. During a time-out, a “plan B” with cross functional teams, was created by management and presented to the group, letting the group know that this would be the teams if the group failed to form cross-functional teams by themselves. The group then formed their own teams, though the end-result was very close to the teams proposed by management. As a consequence of this semi-forced self-selection process, team members were halfhearted in their commitment to teamwork, and sub-teams were formed within the new teams based on the old component teams. The learning is to prepare and educate people more prior to team self-selection.
Also, we realized that some of the resistance towards cross-functional teams was based on people being uncomfortable working in part of a legacy system they were not familiar with
A key learning from this case was that the maturity level of would-be team-members is crucial. For groups with little experience with Agile and team self-selection, it is advisable with crystal clear guiding principles and, in some situations, to have a Plan B prepared which would be the outcome if the group fails to form teams that fulfills the guiding principles.
We also learned that if the process is not converging towards viable teams, timeouts may be an efficient way of getting the process back on track. During a time out, managers or the entire group may discuss what is the cause of none convergence, or the facilitator, and sometimes people managers, may coach individuals who seems to be obstructing the process. In the latter case a coffee break could also be used to make these conversations more discreet.
3.2 Case 2: Form three feature teams without interference (24 persons)
At an early phase in our agile transformation we wanted to merge three component teams into three cross-functional teams. Prior to the self-selection event, we experienced that some of the product owners were trying to influence the process by recruiting their favorite developers. To eliminate the direct influence from Product Owners and Scrum Masters, we decided to exclude them from the event. Instead the Product Owners could pitch their domains just before the team self-selection event started. When the process was completed, the Product Owners were allowed back into the room and we had a joint retrospective on the event and the results.
After two years, these teams are high performing and there have only been minor adjustments to the teams, all due to job rotation. In retrospect, the primary reasons for success were that the former component teams were painfully aware of the impediments caused by cross-team dependencies and that they were truly empowered in forming their new teams without influence from management.
Figure 2: Team self-selection process. Note the pictures of the PO-SM pairs under each slot.
3.3 Case 3: Form two plus one feature teams virtually (18 persons)
For the group of people, where we initially introduced team self-selection, a major change in scope resulted in the need for new teams, as the existing teams would be challenged to deliver end-to-end functionality within the new scope. This called for a new round of team self-selection. The group was at two locations and due to time constraints, we decided not to bring people together and instead to conduct a virtual team self-selection session.
Instead of a board we used an online whiteboard. Participants connected to the board online and placed their photo in their preferred team. The event was held in different meeting rooms with a video link between the locations. We only recommend virtual team self-selection in situations where people know each other well and have previously been part of a team self-selection workshop.
3.4 Case 4: Team members running the process by themselves (12 persons)
The 4th time we ran the process we were in a situation where we needed to re-organize two teams to get a better mix of skills. Re-organization of the teams had been postponed until one of the teams had completed an urgent feature. Everybody was anxious to create new teams as the current mix of skills was creating frustrations within both teams. The Scrum Masters and the Development Managers happened to be out of office for a few days after the urgent feature was completed, so we were planning on running yet another sprint with the existing teams before setting up new teams. However, the teams were reluctant to run another sprint with the current teams and suggested that they could run the team self-selection session by themselves, a process most team members had tried in the past. The teams had also discussed the choice of Scrum Master and decided the Scrum Masters could decide among themselves which team to join. The new teams were cross-functional and viable, and generally the process was a success, which greatly contributed to the feeling of being empowered. Key elements for the success was that most team-members had tried team self-selection before and that most of the people in the two teams knew each other quite well. However, some of the team-members who were not familiar with team self-selection were not entirely comfortable with the process.
So, if you are doing team self-selection with a group with different degrees of experience with the process, make sure to prepare the first-timers well for the process so they are comfortable with the process and can participate under equal terms with those with more experience.
3.5 Case 5: Forming new teams due to scaling (16 persons)
Our 6th attempt was motivated by the need for scaling of two existing teams, with one product owner and one Scrum Master, working on an existing project. To speed up progress on the project, six more team members and a new Scrum Master were to be added to the project. The teams and Scrum Masters would be cross-located at two different locations. This presented us with a challenge; the two existing teams were already high performing teams, adding new people would inevitably force the teams through the usual team forming phases and it would take some time before the new teams would become high performing – if ever. Also, existing team members were skeptical about the idea of adding new people fearing that that new people would be a drag on the teams rather than speeding up progress. Everybody agreed though, that merely adding new people to the existing teams were a bad idea. First, no one liked the idea of two 8 persons teams fearing they would be too big to work efficiently. Secondly, we all agreed that adding people to the existing teams would not necessarily lead to the best team compositions.
It was suggested by the team members that the self-selection process should allow people to select not just a team, but also a feature that the team would start work on. After finishing their chosen first feature, teams should still be able to pull features from a common backlog. The idea was that having a team where everybody would like to work on the same feature would create teams of people with shared interests. To accommodate this idea, we created a two-dimensional team selection board as sketched in Figure 3 below. In Figure 3, a vote in a question mark row and/or column would indicate that one is undecided.
Figure 3: Team Selection board allowing for
team-members to choose both a team and a feature
The challenge in this case was that new teams would be formed out of a group where two thirds of the people knew each other and the project quite well, whereas one third was new to the project and to most of the other team members. To accommodate for this imbalance, we conducted a project intro session for the newcomers where the Product Owner introduced the business objectives and existing team-members described technical challenges. After the project intro for new team-members, we facilitated an introduction session for all team-members, where team-members introduced themselves through a self-intro mind map as shown in Figure 4 below.
Figure 4: Self-Intro Mind Map
In this case, the most important guiding principle was that each team should be able work with both C# and APL code. Furthermore, since we had mixed experiences with cross located teams, it was decided that if a cross located team were formed, the team should, as a part of the team evaluation, specifically discuss how they would work effectively together as a cross located team. To support these demands during the process, we created personal cards for each team member showing location and programming skills. Figure 5 below shows an example of a personal card, as described in section 2.1.
Figure 5: Team selection card showing
location and programing skills
The choice of Scrum Master was not part of the process, since we all agreed that the two Scrum Masters should be assigned to the teams where they would share location with most of the team members.
It took 5 rounds for the process to converge. After the first couple of rounds most people were disregarding the features, and we believe that the option of choosing a feature had little, if any, impact on the resulting teams. One reason for this could be that the features were fairly small, amounting only to a few sprints of work. During the process we also observed that many participants would move to another team when a certain person joined the team they had selected, and we were at the brink of calling for a time-out when the process suddenly converged. As a way of scaling the project, the process has been a tremendous success. The outcome was 3 teams with 4, 5, and 7 team members each with two new people. The two smallest teams were co-located, whereas the last team had 6 people at one location one team member at another location. Four months later all three teams are working well together, and the short-term impact of scaling on progress have been relatively limited.
However, we also learned that from both a practical and ethical perspective, it is important to be aware of people within the group that others have reservations working together with. We therefore strongly recommend that if one person has issues with the rest of the group these issues should be resolved prior to workshop or the person should be removed from the group. The same goes for unresolved conflicts within the group. Unresolved conflicts and other people issues have the potential of jeopardizing a team self-selection workshop. To prevent this in future workshops, we will ask participants to inform their manager prior to the workshop if there are specific people they do not want to be in the same team with.
4. WHAT WE LEARNED
The specific learnings described in the previous cases may be generalized in a model to ensure successful team self-selection. Following David Marquet (Marquet) we know that for a group to successfully act as a self-organizing team, the group must have both clarity regarding what to do and have the competences to do it. In relations to team self-selection, where a group is expected to self-organize into teams that are compliant with some guiding principles, this corresponds to having crystal clear guiding principles and to introducing the process in a clear and unambiguous way. However, this is not always enough. If some of the participants perceive either the guiding principles or the process as a threat, they may not behave constructively. Consequently, the likelihood of successful team self-selection session is inversely proportional to the perceived social threat level within the group. According to neural science, people’s sense of threat in social situations can be categorized into five main domains, known as the SCARF model (Rock):
- Status – our relative importance to others.
- Certainty – our ability to predict the future.
- Autonomy – our sense of control over events.
- Relatedness – how safe we feel with others.
- Fairness – how fair we perceive the exchanges between people to be.
All these threat factors are important in a self-selection context. Prior to a self-selection workshop, the level the social threat level should therefore be assessed, and effort should be spent on addressing people’s concerns. However, all social threats can never be removed prior to a team self-selection session, and the team-selection process by itself is designed to reduce social threats. Specifically, it allows participants to choose teams that will minimize their perceived social threat. Implicitly, our team self-selection model is optimizing for guiding principles and at the same time trying to minimize social threats. Traditional team formation where managers dictate the team, tend to have more focus on the former criterion and have tendency to fail on the latter due to either lack of knowledge or focus on individual concerns. Trouble arises, for our model, when it is not possible to create teams with an acceptable level of social threat that complies with the guiding principles. In the table below we have summarized guidelines for our model based on the perceived social threat level within the group. In the Table 1 we have summarized guidelines for our model based on the perceived social threat level within the group.
Table 1: Guidelines for team self-selection based level of social threat within the group. In the table, everything that applies at lower level of social threat also applies at higher level of social threat
5. CONCLUSIONS
So, is team self-selection the obvious choice? In our experience – with a few exceptions – it is. By taking advantage of the collective knowledge and wisdom of a group, teams can be formed with the skill composition needed to effectively address a business need and at the same time ensure that teams are socially functional and start out with high degree of psychological safety and a strong sense of being empowered. However, if there is pronounced resistance within the group towards the process and/or the guiding principles, it may be better to dictate the teams; in that case one should be aware, though, that the root causes of the resistance, if not addressed, will be haunting the new teams in the future. Therefore, we recommend that, if time allows for it, to postpone the workshop and address the root causes of resistance.
6. Acknowledgements
First and foremost, we sincerely thank our head of Product Division at SimCorp, Georg Hetrodt, Executive Vice President for taking the bold decision transforming our organization into an agile setup, and the senior management team for allowing and encouraging experiments. A big thank you should also go Sandy Mamoli and David Mole for writing the very inspirational book Creating Great Teams: How Self-Selection Lets People Excel. We could not have gained this learning without our colleagues – thank you so much. Your courage and openness to learn and experiment made this possible. We would also like to thank our agile coaches at SimCorp, Frank Olsen and Neil Cook, for constructive and valuable feedback to our work.
Last, but certainly not least, thanks to you shepherd. This paper would not have come together without Maria Paasivaara’s keen insights, questions, and edits: Thanks, Shepherd, we couldn’t have done it without you!
REFERENCES
Rock, David “SCARF: a brain-based model for collaborating with and influencing others,” NeuroLeadership Journal, issue one, 2008.
Mamoli, Sandy & Mole, David. Creating Great Teams: How Self-Selection Lets People Excel, Pragmatic Programmers, 1st edition, 2015.
Marquet, David. Turn The Ship Around!: A True Story of Building Leaders by Breaking the Rules, Penguin, 2015.
