Step 1: Define the Rules and Constraints

Like anything in life, self-selection comes with a few rules and constraints, although we recommend keeping the number of these to an absolute minimum. Keeping the rules short and simple makes the problem of establishing new squads and choosing the right people easier to solve. We believe that the more rules there are, the more complex the puzzle.

The essence of the process is that you are entrusting people to solve a problem, which is why you need to make sure that they have the freedom to do so within sensible boundaries.

Establish the Main Rules

We have only ever had three rules for our self-selection events:

1. Squads have to be capable of delivering end to end.

2. Squads have to be made up of three to seven people.

3. Squads have to be co-located.

Here’s the reasoning behind our rules:

Keep Squads Autonomous

Squads have to be capable of delivering end to end.

You don’t want to create a web of interdependencies. Squads are given autonomy, and you can’t have autonomy unless people have the ability to work on their own. This means squads must have all the skills to work end to end. To become a self-sufficient unit they can’t be relying on anyone outside the squad. This doesn’t mean that they need the best people; it simply means that they need people with all the skills or the ability to learn these skills to move from an idea to a shipped product or feature.

Keep Squads Small

Squads have to be made up of three to seven members.

Experience has shown us that smaller squads work best. While smaller is usually better, two people is a pair and not really a team—so the minimum number is three. We’ve also experienced that teams larger than ten become unwieldy and unproductive, and they often form subgroups that can introduce conflict.

Agile experts often assert that teams should be made up of seven plus/minus two people;^[6] however, we prefer even smaller teams where possible. This encourages cross-functional collaboration and supports the concept of members wearing different hats rather than only performing tasks within their respective professional fields. (Examples include testers doing business analysis and developers volunteering to test.) Small teams also make communication easier because there are fewer communication paths among all members—the number of communication paths increases significantly as the number of people increases.

There is an equation to calculate this:^[7]

The number of communication paths per team member is shown in the following chart.

We recommend you set the number of people as a clear constraint and to allow the squads to work out how they will manage within that constraint. In our case, if they asked questions such as “Can we have half a person?” our answer was “Absolutely, if you think that this is the best available option and fits the constraint.” As it turned out, those who suggested half a person later always withdrew that suggestion when they considered how this would work in reality.

Keep Squads Together

Squads have to be co-located.

If you can, keep your squads co-located. Co-location is one of the most important features of the highest performing software development teams. While it might be possible to create squads across locations, it will make communication and collaboration so much harder. Sometimes distributed teams can’t be avoided, but if you can work from the same room, we recommend you do so!

Don’t Specify the Outcome Before You Start

We’ve usually been asked and always resisted requests to specify up front the number of senior and/or junior members for each squad. The intention of the request can be to ensure that the right amount of technical know-how is present and that there is an even distribution of the most experienced people across squads. However, this request assumes that preselecting based on those features would be more successful than choosing on the day. To us this feels uncomfortably like management selection.

If you did choose to take this additional rule on board and specify, for example, one senior developer for every squad, you could easily find out on the day that you don’t have the right ratio of talent in your organization. This particular request also assumes that one senior person is interchangeable with another, which isn’t true of senior developers any more than it is of any other role.

Not bowing to the pressure to add rules of this nature also prevents a highly undesirable outcome, that in which employees perceive that they’ve actually been selected into predefined allocations and it wasn’t self-selection at all. It’s our belief that the only thing worse than management selection is a fake version of self-selection where people are led to believe they will self-select only to find out the decision wasn’t theirs at all, and due to the rules and constraints, their new position was effectively preselected.