Report on a Team Self-Selection Process

The structuring of teams is a central issue in software development, both for their efficiency and ability to deliver quality products. Concepts such as Amazon's famous 2-pizza rule, which states that a team should be small enough to feed itself on two pizzas, or Daniel Pink's principles of autonomy, illustrate the importance of designing teams capable of operating autonomously and in alignment. Adding more brute force to a team with fingers crossed, like setting an oven to 1000 degrees to cook a pizza in 1 minute, doesn't necessarily lead to better or faster results.

On the contrary, a thoughtful, need-driven organization based on trust can improve key metrics such as code review time, change lead time and teams' sense of commitment. In this context, we explore the impact of an innovative approach such as self-selecting teams.

The Challenges of Large Teams

At the start of the project, the team comprised 14 developers (including 2 team leads), 1 product owner, 1 designer and 2 quality assurance specialists. It's easy to imagine how this could make many aspects of teamwork complex, especially regarding communication. The diagram below shows that as the number of team members increases, so do the number of “lines of communication”.

Evolution of communication channels in relation to team size

Here are a few more concrete examples of the challenges encountered at the start of the project when the team formed a single large team:

• Too many people in meetings: with 18 participants, meetings become chaotic. Consensus is challenging, focus is lost, and much time is wasted.
• Lack of accountability and responsibility: the more people involved, the less clear the ownership of tasks. This leads to unassigned actions, neglected responsibilities and disengagement.
• Overlapping tasks: in a team of 14 developers, managing work in progress (WIP) is complicated. Tasks overlap, slowing progress despite parallel work.
• Dilution of responsibility: when too many people are involved in a code review, everyone assumes that someone else will take care of it. The result: reviews take longer or aren't done efficiently. This concept is called responsibility dilution.

It's a safe bet that you've already encountered these challenges in various contexts.

Introducing Self-Selected Teams

One solution may be pretty simple: separate this team in some way to try and increase productivity and reduce wasted time. It would have been easy to let the managers do the splitting themselves, given their 360° view of the team.

But why not let the team members choose?

This is where the concept of the self-selecting team comes in. Overall, the exercise is relatively straightforward:

• Definition and presentation of the different teams available and their mission;
• Explanation of the rules and constraints (as few as possible) to be met by each team, leading to completion of the exercise;
• Selection round(s):
  • Each individual decides on the team of their choice;
  • The sub-teams form and meet to assess whether they meet the constraints;
  • Each team presents its challenges: if the constraints are not met, the process starts again;
  • Continue until the teams meet the constraints or until the troops are exhausted.
• Once the teams are complete and the constraints have been met, wrap up and inform the teams of the next steps (setting up the teams).

Self-selected team formation process

Within the scope of our project, there were:

• 3 features to be initiated in parallel and therefore 3 possible sub-teams;
• The constraints were :
  • At least 1 developer from the client's team on each team to share knowledge of features;
  • Each team had to be capable of bringing the feature to completion, which meant having a variety of complementary strengths.

The trick here is not to be afraid and not to hesitate. “What if a team is only made up of juniors?”, “what if no one wants to work with this person?” or “what if no one wants to work on feature X?”. By following the process, the constraints and trusting the team members, self-selection will always be possible.

Finally, after just 1 selection round, the teams were complete. The result was 2 teams of 3 and 1 team of 5, keeping the 2 team leads, the product manager, the designer, the QA specialists and 1 experienced developer “floating”.

Although many other things changed in the project, the separation into self-selected sub-teams became a catalyst for many positive initiatives and results.

Observed Benefits

Returning to the challenges mentioned at the beginning of this article, let's now look at how the separation into self-selecting sub-teams helped to resolve several of the challenges faced by the team at the start of the project.

• Too many people in meetings: with smaller teams, meetings become more dynamic, productive and relevant, because they only involve the required members.
• Lack of accountability and responsibility: teams have now chosen what they work on and with whom. This is naturally more engaging. The team's purpose is better defined, and task sharing is much quicker since choices are more limited.
• Overlapping tasks: each team has its end-to-end features, reducing confusion and increasing speed thanks to adapted practices such as pair or mob programming.
• Dilution of accountability: code reviews and delivery times have improved significantly as reviews become targeted at a particular sub-group that is more accountable.

What do the numbers say?

As soon as the sub-teams were introduced, a breath of fresh air took over. Teams seemed more committed and aligned, and less time was wasted. But what do the figures say?

We noticed significant improvements within 5 months of setting up the self-selected sub-teams.

Regarding code reviews, we measured a 60% drop in total code review cycle time and a 67% drop in code review handling time. It is interesting to note here the reduction in dilution of responsibility, which becomes a key factor impacting these figures.

Evolution of code review time over the 5 months following team self-selection. Captured from our tool Axify.

Moreover, the lead time for changes from implementation to deployment was reduced by 63%, representing a significant difference in the development process.

Evolution of lead time for changes over the 5 months following team self-selection. Captured from our tool Axify.

The above metrics are also influenced by several other factors and initiatives implemented during the project. Always doubt the numbers! But with a set of metrics, it's still possible to get an overall idea of the result.

What do the team members say?

Aside from the numbers, what are some of the team members saying? How did they feel after the change? Three team members were interviewed as follows:

• Describe in one sentence the impact the change to sub-teams had on you;
• From 1 to 10, note the following 3 aspects, before and after the change:
  • Overall perception of ability to deliver changes
  • Commitment and satisfaction
  • Perceived productivity

Here's what they had to say, and below the scores they gave to the various aspects before and after the change:

The separation into sub-teams reduced the mental burden of keeping track of all the initiatives underway. It enabled us to refocus priorities to see the work that needed to be done clearly.

– Francis, Developer

The separation into sub-teams gave me greater focus, a close-knit work team and better ownership of the features I was working on.

– Jeanne, Developer

We feel more responsible for what we're working on, so we're more actively involved, but at the same time, it makes it easier to let go because we know what we can leave in the hands of others. So, paradoxically, we let go more, but we're also more involved in the end.

– Mylène, Developer

Conclusion

First of all, it should be noted that introducing the sub-teams was only one factor among many that led to these significant improvements. On the other hand, it is valid to assume that the advent of self-organizing sub-teams was a catalyst for several other initiatives, such as:

• Involving the development team right from the writing stage in the creation of user stories;
• Creating rotation teams to handle emergencies or external requests;
• Implementing different work methods such as pair, mob and synchronous code reviews, all adapted to sub-teams.

It's also essential to take a step back from what led to this change. At the start of the project, a similar idea existed, in which management would separate the large team in a predefined way, and each sub-team would have a clear role. This idea generated a lot of friction and was ultimately not implemented. Yet, only a few months later, the team arrived at a similar result: by letting the need emerge and letting people choose rather than imposing it without responding to a precise need.

Key points

• Humans like to have autonomy;
• A smaller team means more focus and ultimately faster delivery of the “right thing”;
• It's essential to live through and accept a period of adversity to come up with solutions that meet real needs;
• Don't be afraid to innovate to eliminate problems.

Who knows, maybe you could mix up your teams occasionally, leaving the choice up to the team members!