Is Reteaming Something for You?

Author: Jurgen Appelo

Let me be clear: reteaming is NOT resourcing. Resourcing is moving people around projects and products like cattle in a barn. Reteaming is people choosing to work in different contexts in a voluntary, autonomous, and self-organized manner.

There's quite a bit of buzz about reteaming these days. The topic comes up at every event I visit. Reteaming in an organization can boost innovative capability and employee engagement while, at the same time, it comes with the risk of productivity loss and loss of motivation. However, the benefits can outweigh the drawbacks if you manage it well.

Permanence and Permeability

There is understandable confusion about what reteaming is. Does it mean that people regroup as different teams every day? Or does a simple annual team reshuffle also count as reteaming? To bring some more clarity to the discussions, I propose a simple classification.

What does it mean to be a team?

There are countless ways to answer this question.

One way is to look at the permanence and permeability of boundaries. Team boundaries can be stable over a long or short time, and they can let many or few people through. In other words, teams are long-lived or short-lived (permanence) and have static or variable team memberships (permeability). This gives us four basic teaming option patterns, which help you understand your options when forming teams.

Steady Teams

A Steady Team has high permanence and low permeability. It is long-lived, and team membership changes rarely. People are each other's team members for a long time. Such a team is a good option when their work is an ongoing responsibility with a steady workload. A Steady Team may also provide a sense of belonging, cohesion, and recognition when the surrounding environment does not offer this sufficiently.

An example of a Steady Team is a product team in software development. The team "owns" the code; there are few or no changes in team membership, and the team exists for as long as the product does. This is a typical pattern we find in various agile product management methods.

(Your marriage, assuming you have a spouse and you're happy to see each other, is probably a Steady Team, too.)

Dynamic Teams

A Dynamic Team has high permanence and high permeability. A Dynamic Team is long-lived, but team membership changes frequently. People move in and out of the team on a regular basis. You can choose this option when the work is an ongoing responsibility, but the workload has a level of variety that cannot be flattened. This is also a good option for offering people more variety in their work.

An example of a Dynamic Team is a service team in a call center where the team "owns" the service. But in this case, team members repeatedly come and go while the team (with members rotating in and out) exists for as long as the team offers the service.

(With spouses added, babies born, and elders passing away, your extended family could sometimes behave as a Dynamic Team.)

Mission Teams

A Mission Team has low permanence and low permeability. A Mission Team is short-lived, but membership in this team rarely changes. People are each other's team members for only a short time. Such a team is a good option when an objective requires a small number of people having roughly equal contributions to the goal over a similar period.

An example of a mission team would be an airline crew or a rescue team. They work together briefly to achieve a specific goal or to deliver a particular project. No team members are rotating in or out for the mission's duration.

(That annoying student assignment you worked on with fellow students many years ago was a Mission Team.)

Liquid Teams

A Liquid Team has low permanence and high permeability. A Liquid Team is short-lived, and team membership changes frequently. People are each other's team members for a short time and in different periods. Choose this option when an objective requires a small number of people with unequal contributions to the goal over different time spans.

An example of a liquid team would be a film crew or a construction crew. These teams work together for a short time to achieve a specific goal, but the team members (usually professionals and specialists) may rotate in and out continually.

(The goal-driven charity project you contributed a few hours to on a quiet Saturday morning was a Liquid Team.)

Team of Teams

Some risks often associated with reteaming are a loss of productivity and demotivation (due to decreased belonging, competence, certainty, etc.) An excellent way to counter these risks is by ensuring that any reteaming happens within the same Turf or Base.

A Turf is the name we use for a shared area or territory of technologies and working methods. A Base is the name we use for the larger group of people that remains static and offers a sense of belonging, appreciation, and recognition. When the Turf and/or Base stay the same, reteaming becomes much more manageable. You may get the benefits without the drawbacks.

The Turf Type we introduced to facilitate reteaming is called Team of Teams. When the Base is relatively small, it may function as a Team of Teams.

Examples

In the case of Red Gate Software, reteaming happens annually, which means we can see their teams as a weak form of Dynamic Teams.

In the case of the Pipedrive, the tribes themselves are Steady Teams, but within each tribe, the Launchpads are focused on Maintenance, while their Mission Teams are ad-hoc teams that do everything except Maintenance. It's a great example of combining three patterns: Dynamic Teams, Mission Teams, and Team of Teams.

In the case of Fluid Scrum Teams, FaST Agile, and Tesla, reteaming happens with Mission Teams because people are swarming around individual tasks and experiments and then form temporary teams to get that work done.

Different Contexts, Different Choices

Naturally, the best teaming option depends on how the benefits and drawbacks of each pattern play out for your organization. That is for you to figure out. Don't believe anyone who tells you long-lived, stable teams are your best option. Such people need to pay more attention to the broader world around their narrow domain of software product teams. (Even within that domain, case studies such as Pipedrive Unfixed prove them wrong.)

There are good reasons for preferring long-lived teams, but short-lived teams may be the better option in some environments. Static team membership is often good, but variable team membership sometimes makes more sense.

Discuss these patterns with your teams and consider your options carefully.