There will undoubtedly be some challenges in an Agile transformation, regardless of size. One of those is how to reorganize the teams around the work that we have to do while fitting into the template of small, cross-functional units that can operate both independently and interdependently.

As teams grow in size, and we have multiple teams working on various inter-related products or parts of a product, it gets harder for leadership to work out who goes where and be best placed to solve the challenges we have.

Many people will be affected by the decisions that leaders make as to how the company is going be organized from here on out. There is a degree of powerlessness that everyone at the team level will feel as they try to come to terms with their new roles and team reorganization. If we make them an active part of the process, in my experience it will go much more smoothly.

And just as we've shown in this book, when faced with solving a complex product problem, if we take the problem to a bunch of smart, capable people (the members of our teams) and set the right boundaries (purpose, vision, mission, objectives), they will work with us to help solve it. 

This is just what we did with our teams in 2015 when faced with the reorganization of new team objectives. The following is a reflection on our experiment by my colleague Jaume Durany:

Our mission at that moment was to rewire the current teams in order to face new business goals in the best possible way while empowering self-organization. Instead of trying to manage team formations, processes, and workflows up front, we decided to start by applying the team self-selection experiment shared by Sandy Mamoli and David Mole to kick off our new teams. In less than one hour we had our new teams defined and balanced by the same people forming them.

The team self-selection activity was a really good example of how to promote self-organization by setting up the right boundaries. Our effort was focused on defining, structuring, and presenting the boundaries of the process so that everybody was aligned to face every decision in the best possible way.

The boundaries defined were business goals that the Product Owners pitched for their teams. Then the self-selection process was introduced and kept on the board so that the choice was based on three simple questions in priority order: "What is best for the company?", "Where would I be more valuable?", and "What do I want to learn?"

Our next step was to follow the same approach to come up with all the agreements needed to start working as a team. We decided to make use of visuals to define the boundaries of every discussion and facilitate the emergence of a team consensus around the minimum set of artifacts and ceremonies needed: the board, the Agile methodology, the alignment of communications with remote team members, and the working agreements.

The result of this experiment was truly exciting. We only spent 5 hours and 30 minutes, divided into five sessions during one week, to completely redefine our teams and, more importantly, every single step came from the teams. They'd self-organized since the very beginning to define their initial setup. We kept asking for feedback during the whole experiment and it was really helpful for us to keep adapting the visuals and the boundaries to their needs.

Since then, our main goal has been to keep the same principle in mind, keeping our focus on managing the boundaries and the environment to make sure that what emerges from the teams’ self-organization has value to them and to the organization. Focus on managing boundaries and people will manage themselves.

I see self-selection, or at its base level, self-determination, as the catalyst that triggers self-organization. The reason self-selection is such a good exercise to go through is because it triggers the thought process of doing the right thing by the company, by your team, and then by you. You have to put the business and the team first. This is the core of the Agile movement to my mind—a responsible "service"-orientated culture.

As our hierarchy flattens, and with it the resulting network of teams, it probably follows that we need to have more fluidity with team membership to take advantage of the close collaboration of areas of our business.

Sometimes, this is because we have specialist skills that need to be shared around; sometimes it is because the team mission changes direction and people find themselves no longer making a full contribution. Sometimes it is because people feel they have a passion for another team's mission and can make a fuller contribution there.

Whatever your reason, there is a case to be made for setting up a "player transfer" system in your organization. As long as we set the appropriate boundaries, for example remembering that team stability becomes affected if membership changes significantly, then we should be able to easily accommodate a degree of movement between teams.

The easiest way to provide insight for our teams on how this might work is by walking them through some real-world examples. If we teach the team how to think about a reteaming event, they will be able to incorporate it as part of their toolkit.

For instance, imagine we are being asked to build a new product. Our reteaming strategy will likely be influenced by how the new product integrates with our existing product line.

If the new product is completely separate, no connection, we could form a new team and hire all new members. We’d have to onboard the team and instill our company culture, but this team would be able to operate independently of the others.

If the product is linked somehow to our existing product line, we will likely look to seed the team with existing team members. There are two strategies for this based on how tight the coupling is:

• If it’s loosely coupled, we can seed the new team with one or two existing team members and hire the rest. We want the team to have enough information about the existing product to get started.
• If the product is closely coupled, we would look to split an existing team, and add new team members to each. An in-depth knowledge of both the existing and new products will be required by each team. At the inception of the new product, both teams will likely work closely together.

The preceding example is for forming a team around a new product. Sometimes we just want to form a team temporarily, for example, so we can build a shared service. We could do this by asking each team with an interest in the new service to supply the temporary team with 1 or 2 members. They would operate as a new team until the shared service has been implemented. The team members would then return to their original teams to share the knowledge of the new service.

The final example is where we have specialists who join teams temporarily to coach certain skills. The specialists would operate like an agency, going where they were needed the most. They will often temporarily join a team as a fully fledged member and work with them in the team’s preferred style, either pair or mob programming so as to transfer knowledge.

The preceding are just a few examples of reteaming strategies. Once teams become familiar with the different approaches and understand the boundaries, it paves the way for them to become more fluid in their team membership.

In her book Dynamic Reteaming, Heidi Shetzer Helfand shares further examples.

When we combine self-organization with the need for team membership to change, "reteaming", we create a powerful thing indeed.