Self-Selecting Teams Part 2 - Keeping the Momentum

Sandy Mamoli, Nomad8, nomad8.com, @smamol; David Mole, @molio

In this second and final part of our article on self-selecting teams, you will learn how to get your self-selection event off the ground. We will also provide tips on how to get the most out of it and keep the momentum going afterwards

In the first part of this article [1], we wrote about what self-selecting teams are, the problems they can solve, and how to prepare for and run a self-selection event. We included a preparation checklist:

• Readiness check
• Run a trial
• Define the teams
• Logistics of who, when, where
• Communication
• Rules and constraints
• Prepare materials

You might want to read Part 1 and review these concepts before reading Part 2.

5. Permission versus forgiveness

Once you have decided you want to go with self-selecting teams, you're going to have to convince others in the organisation that it is a good idea. It is unlikely, however, that you're going to get complete buy-in for self-selection at the outset. If you know you can, great. But depending on where you are in the management hierarchy you may find that seeking forgiveness after the fact, rather than asking for permission beforehand, is the best way forward.

We know from experience that people will likely feel scared or challenged by a concept like this in the beginning, so if you start by asking for permission and don't get it, then your project is over before it is begun. We didn't have full buy-in at our Kiwi eCommerce provider in the beginning, but at least it was an organisation that operated on trust where people were inclined to give you enough rope to try something new.

We felt we needed to just go ahead and do it rather than try to persuade everyone at first. But while we didn't ask for permission, nor did we act like cowboys. We moved slowly and kept everyone in the loop along the way. Our aim was full transparency from start to finish. In fact, we probably erred on the side of over-communicating, but at least it was communicating what was actually going to happen rather than asking if it would be a good idea.

We worked a lot on risk and were very honest about the fact that we didn't know for sure whether this would work. What we did know, however, was that the worst-case scenario wasn't so bad. Ultimately the worst thing that could happen would be one day's lost productivity (which we put a dollar value on) if it didn't work, and then we could easily move back to managerial selection.

And that's what we talked about, the small size of the risk, rather than letting people imagine awful scenarios of developers fighting each other in the corridors or a complete breakdown in our current structures. We were also in a position of strength having already run a trial event, which meant we knew what was to come and could manage expectations accordingly.

6. Communication: early, often and honest

Communicating well might be the single most important thing you can do to pull off a successful self-selection event.

We've seen a pattern emerge when people first hear about self-selection. The first reaction tends to be positive but it can move quite quickly to fear and resistance. Fear of something new and different, fear of what might happen, fear of being stuck with someone you don't get on with or of being stuck in a team that you can't change your mind about later. People had a lot of questions, which was only fair: we were not only asking them to choose who they worked with but in most cases to adopt a new way of working (Scrum, Kanban or whatever combination of Agile ingredients the new group would decide).

We were bombarded with emails, meeting invites and questions from all angles. In the early stages we fielded a lot of 'what if' questions. 'What if someone gets picked on during the event? 'What if no one wants to join a particular team?' We were fairly confident from our trial that these things wouldn't happen but we were also able to answer that we would be facilitating the session (so no bullying) and if no one wanted to join one of our teams that would actually be useful information that we would take away and have a look at.

As time went on, and people moved through 'stages of acceptance', we started to get requests for rules and trade-offs. A bit like 'Okay, I'll try your self-selection process but first you have to do something for me'. Some people requested rules for the event that would make them feel more comfortable. An example was a request for every team to have both a junior and a senior developer.

We politely resisted these requests, though, because each one could have caused a ripple effect that made the problem more difficult to solve. We were also confident that the teams themselves would know best what level of seniority would work for them. We felt this was a critical point in the process and if we'd given in and added rules on request we wouldn't have had such a successful day.

Based on our experience, we recommend the following approach to communication:

• Talk to as many people as possible, from start to finish
• Actively listen to their concerns
• Be patient with people as they work through their fears
• Record people's fears and what-if scenarios
• Manage risks actively
• Paint a very honest picture about the worst-case scenario, which is never as bad as people think
• Talk to people individually and present in groups
• Show real examples from your Ship-it Days, trials and from other companies
• Ask people whether it is they, or their manager, that knows more about where they should be placed

7. The dynamics of self-selection events

We have facilitated four self-selection sessions in various locations and have talked to several companies who have followed our principles and process for self-selection. We have observed a number of patterns that emerge almost every time. 

7.1. It takes three rounds

Every time we facilitated a self-selection session it took people three rounds of 10-minute iterations to get the hang of things and to arrive at a good solution. 

Usually round one is not very successful. People manage to create very few fully formed teams and most of the teams are either wildly over- or under-subscribed. For example, one of our first-round teams consisted of 7 developers and no one else. 

Round two is where things start to improve and this round usually results in more fully formed teams. There are still some over- and some under-subscribed teams though. 

In round three magic happens. People understand the process, they start talking and teams begin to lobby for members. Negotiations and swaps happen and some Product Owners or team members re-read the team pitches to attract potential members. 

7.2. It is all about relationships

It is interesting to observe what people base their selection on. The most important appears to be personal relations - who people want to work with and who they don't want to work with. That said, it can be hard for people to admit this up front. In a survey we conducted after our largest self-selection event, most people said they had based their choices exclusively on doing what was best for the company and what type of work they wanted to do.

But that ran contrary to our observations: during the day most of the conversations we overheard were about who wanted to work with whom and we noticed that many people were only "available" in twos or threes. Often when one person moved, other people moved along with them. Also, people who had not been able to make it for the day were allowed to nominate proxies to make a selection on their behalf. The most frequent instruction to proxies was to "just make sure I'm in your team".

Sometimes people don't want to work with each other. And that's okay. People know whether or not they're going to gel in a team with a particular person and if not it makes sense that they would choose not to work with them. During our biggest self-selection day we observed two people in particular who seemed to have taken a dislike to each other. When one of them moved their photo to a team the other one was in, the first one would move their photo to a different team. This happened several times and whenever those two coincidentally ended up in the same team one of them would move again. 

And this wasn't a problem at all. There were no dramas and the people who were affected made a choice that was good for them and their teams. Had they been selected to work together, as they easily could have by managers focusing only on compatible skills, both they and their teams would have suffered. 

Sometimes it was hard for people to leave an existing team. As one participant put it: "I didn't like the sick feeling I felt moving out of my existing team - didn't like 'hurting feelings' (for want of a better phrase)."

Interestingly, people seemed to believe that they were supposed to choose without taking personality into account. This is probably because they felt choosing people's personalities over their skills would have resembled a popularity contest rather than an optimum team selection exercise. However, we noticed that people seemed to select who to work with based on similar values rather than who is popular or who they like going for a beer with. 

7.3. Most people like the process and the results

After each self-selection session we survey people about their experiences and expectations. We ask what they think of the process and whether they like the results. 

Every single time our results have showed that by far most people like the team they end up being part of. Surprisingly, most people tell us that they now work with the team they expected to work with, so people seem to go into the day with some expectations about the outcome already. After the day, almost everyone is in favour of self-selection as the best way to design teams. Even people who initially fear and doubt the process come away with a positive attitude.

At our eCommerce business it was interesting to notice that people in their 30s and 40s, who had been in the workforce for longer than others, had much more awareness of what a privilege the opportunity to self-select was than recent graduates. People in their first jobs probably assume this is normal and that's not a bad thing: hopefully, with their expectations and experience, it soon will be. 

There will always be people who don't like the idea of self-selection and we have never forced anyone to participate in any of the sessions. We have always given people the opportunity to opt out by leaving their photo in a "Need a team" area where other people can pick and assign them from. The opportunity to opt out is important, not only for people who don't want to take this kind of responsibility but also for those who are very new to the business. Picking a team in your first week on a new job is a lot to ask.

Here are some of our favourite quotes from our surveys:

"It gave great insight into what other teams and parts of the business do."

"People had equal opportunity to do what they really want to do / think they would be good at."

"It is good that people could decide for themselves, and trust was given to do this well."

"The set-up and agenda were explained well and it was an easy-to-follow process."

"Freedom! Fascinating to see how it all worked out. Excellent result, and nice to know we were able to achieve it without having to get nasty or dictatorial."

"It was a good way to bring issues to the fore quickly and show them visually. I kind of liked going round and seeing whether squads were formed or not."

"I did not observe tension or conflict, which was a great thing. Proved that this was a valuable exercise."

"It did give people the chance to choose where they wanted to go but everyone was also thinking about what would work best for the company."

"People self-organising, surreal."

"Got to chat with people I'd only seen around the office but not really met yet - only been with the company for 4 months. Also the fact that we actually get to do this at all. Would never even have been considered in my last company."

7.4. It really worked for the company

One of the greatest wins was that people proved that they really can be trusted to solve complex problems in a way that's best for the organisation. People in teams who had the privilege to decide for themselves who they wanted to work with weren't the only winners. As an organisation we learned a lot about what people actually wanted to do and some of this information will be very useful for future hiring. For example, after the first selection round almost all developers had moved themselves into teams focusing on back-end heavy projects, leaving the more front-end and design-centric teams.

For management it was really good feedback to have some areas of the company highlighted that are less appealing - potentially because of the particular match of people and interests or because of the way those areas were managed. It provided a great opportunity to dig deeper and to ask the right questions. Also, the gaps we were left with could drive our future recruitment, which was an important takeout from the day.

Self-selected squads have been more stable than the teams we selected as managers prior to this. They also appear to be more productive and we have seen fewer personality clashes and petty disagreements. Overall, people are happier, teams are more stable and our delivery is better and faster than it was before. Our internal measures tell us that we have a much greater output and higher quality. 

8. After the event: the beginning not the end

A successful self-selection day is just the beginning. We came out of our largest self-selection exercise with 11 pieces of paper of photos and names. While they were a perfect starting point they really were just 11 blueprints for teams. Next we needed to create the teams in the real world.

8.1 Expectations

Coming out of the day people have a lot of questions about what's going to happen next, when they can start working in their new teams, and whether this is actually for real or if there will be some last-minute management decree that changes some or all of the team designs. 

For us the first thing was to follow up with each team (11 within a week) to discuss ideas, concerns and to find a start date. We ran a meeting with each of the teams using the Lean Coffee [2] format where we not only managed expectations but also handed over some responsibility to the teams to make it happen.

Three main themes emerged during the Lean Coffees: 

• When can we start and what happens to our current projects?
• Are we adequately resourced?
• How will seating work?

It is a great sign of people's engagement when they are concerned about their current work and don't want to abandon existing projects. However, all those ongoing projects had created a web of dependencies that we needed to break. New hires were also an issue: some teams were waiting on a new designer being recruited, for example, so they couldn't start until later. 

In general, we agreed on the guiding principle that no time is ever a good time so, if in doubt, go for sooner rather than later.

8.2 Creating teams

As we were a pretty big organisation with many ongoing projects and we were growing rapidly, it took us almost three months to finish the process of transitioning existing projects to the new teams and disbanding the legacy structures. Among our considerations were the projects, people leaving, a month of Christmas holidays, and new recruits, and we were also very aware of a danger that management could stop us if they felt the process was starting to cost too much in time and disruption.

Looking back it was fascinating to see how those three months were filled with little bursts of new teams starting when a new person arrived and freed up a group of people. It was a bit like when the perfect shape comes down in Tetris and we could fill 3/4 lines at once.

During the transition it was helpful to make the timeline visible to everyone in the organisation. We displayed a big wall calendar with planned start times for teams and checked off teams as they launched. We believe that the transparency was an important part of keeping things going and not losing momentum. If there's one thing we would add next time it would be regular follow-up meetings every other week or so with the not-yet formed teams to keep their focus and buy-in.

One of the main concerns people had was whether their teams were adequately resourced. We found that people often fell back into emphasising roles over skills: while we had made sure that everyone bought into the idea that a team needed a certain number and spread of skills (depending on the team's work) and that these skills weren't necessarily the same as roles, some people still felt insecure about whether they as a team had enough of the requisite skills.

Fundamentally, this was a sign that some teams didn't feel confident yet that they were up to the task and people understandably felt nervous. This is a natural part of any team formation and while we weren't too concerned we reassured teams that we trusted their self-selection and that if, after 3 months, they found they needed another or more of a particular skill, they would be allowed to hire into the team. 

8.3 Kicking off teams

With things falling into place and new teams starting in rapid succession, we needed to make sure that the new teams were off to a good start. After all, 30% of a team's chance for success depends on how they kick off. [3]

During self-selection we proved that people can be trusted to solve complex problems, know what's best for them and the company and, in general, be treated as the adults they are. In the spirit of letting people be in control of their way of working and finding a way that works for them, we don't mandate whether teams run Scrum, Kanban or any magic mix of Agile ingredients (or even Waterfall, for that matter, but no team has ever chosen that). 

We believe it is important to maintain the spirit of self-organisation and to make sure teams understand that the trust and control they were given when designing their own teams wasn't a one-off. It was ongoing. Truly high-performing teams need to be in control of the way they work. When new teams started we guided them through a process of selecting Agile and Lean practices to help them come up with a process that works for them. [4]

8.4 Supporting teams

After the initial kick-off, ongoing support is important and we offered support, training and coaching to all our teams. We were constrained by the fact that we had only two full-time Agile coaches, so we worked on growing more internal coaches. We set up a structure which enabled people to help and support each other as much as possible. We had an Agile Coaching Guild and offered things like book clubs and suggested reading while also trying to pair people up so they always knew where they could go for support.

9. Go and do it!

Self-selection honours the principle of trusting people to be responsible adults who can solve complex problems and organise in a way that's best for the organisation and themselves. We believe that companies get the best results when people can choose what they work on and who they work with.

Now it is your turn to go and do it, to try self-selection and test your own hypotheses around whether this could work at your organisation.

You can use our two articles as your cheat sheet but if that isn't enough then the following resources could also be helpful:

• Use our Team Self-Selection kit, where you will find all the parts of the toolkit you will need: http://nomad8.com/team-self-selection-kit/
• Read our blog article of when we trialled the process originally: http://nomad8.com/the-self-organising-organisation/
• Read our blog article from when we ran the biggest self-selection event that we believe has ever taken place: http://nomad8.com/total-squadification-large-scale-self-organisation/

Bear in mind that it will never be a good time to do this, you will never fully clear the decks and get all your projects to a perfect state of completion. So go ahead and jump right in!

References

1. Self-Selecting Teams - Why You Should Try Self-Selection
2. http://leancoffee.org/
3. http://www.estherderby.com/2011/11/miss-the-start-miss-the-end.html - sthash.65FkEH9y.dpuf
4. http://nomad8.com/how-we-kick-off-new-squads/

---

Agile and Scrum Resources

Scrum Expert

Agile Videos and Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Spring 2015 issue of Methods & Tools