Teams are never stable, like it or not. People come and go, teams change, better get good at it. This is the premise of the book Dynamic Reteaming: The Art and Wisdom of Changing Teams, by Heidi Helfand.
She starts her book with the concept of an eco cycle, which she uses as a metaphor to explain team stages. Below is a quote from her book elaborating on the idea.
In the Los Padres National Forest near where I live in California, we can witness the ecocycle of oak trees firsthand. At a very high level it works like this: Acorns drop from the trees. They find their way underground and take root–like a birth phase. Next is the adolescence phase, in which the young oak trees grow and grow and grow. Then there is an accumulation taking place as the forest becomes denser. The trees that thrive get really thick and develop canopies—they are in the maturity phase. The trees that do not do well might never get to adolescence and will instead struggle and probably die off. This is akin to being in a poverty trap, or a situation where there is a failure to thrive. After a while, in a mature forest, the trees might get brittle and their growth might be slowed. It’s like a rigidity trap, where the life appears stifled or not as expansive. It could even appear stagnating. All of this is the opposite of thriving. In times of drought it can be even more pronounced, incredibly fragile, and even dangerous. Just a small spark can cause a catastrophic wildfire and burn the trees to the ground. This is the place in the ecocycle that evokes some kind of disruption or destruction.
I memorize teams lacking the ability to improve and find themselves stuck in the poverty trap. Sometimes teams stagnate in growth when they miss outside stimulants or become blind to their problems and find themselves in the rigidity trap. According to this cycle, there are plenty of reasons to re-evaluate and change teams.
The question is how do you undertake such effort. Therefore, she came up with a few patterns.
One by one pattern
This pattern spreads out new hires to separate teams.
New hires get added to 1 existing team and once the team gets "too big" they will split up.
Put people from 1 or more teams in isolation. It is easier for the isolated team to behave like a startup and move quicker.
Merging 2 teams into 1. The idea is the combine teams to get their collective intelligence to tackle a specific challenge or remove constraints between those teams.
As you would expect, a pattern where a team member joins a different team.
These patterns give good ideas about evolving teams, but undertaking such a process is not simple.
To successfully reteam, you need to figure out where the team is on the eco cycle and remove organizational constraints.
How team members collaborate impacts the ease or difficulty of reteaming. When there is information overlap between people on a team, it's theoretically easier to reteam.
The book states that employees' coding alone restricts dynamic reteaming. Whereas pair programming eases a bit of this restriction.
An example given of alleviating restriction by using pair programming is in a big organization where they let new hires continuously pair with seniors. They found new hires are quicker to adapt to company culture and knowledge. When the company grew in size, this didn't scale anymore, as the quality of teams diverged. Their solution? They grouped newcomers, give them basic training on expected quality, and afterward let them continuously pair with seniors over multiple teams. This gave new hires insights on company culture and knowledge, plus the new hires end up with an informal network within the company.
Altho Pair programming is great, mob programming would be better. Hunter industries, the company where mob programming, are actively practicing incorporating ever-changing teams. Employees in those teams may roam freely between teams if they find somebody willing to trade places. After trading places, they will notify management. This way, employees could swap teams on their terms. It's great when you don't fit that team, or you dislike the product or the software doesn't attract you.
People come and go, teams change, companies change. Heidi's case to build organizations around ever-changing teams is great. Employees get productive quickly and feel the freedom to move around an organization!