Moving the people or the work?

Organizations that embrace the Agile principles apply the ground rule that teams should be stable. When you see teams as autonomous units of multidisciplinary professionals who are trained to do their jobs as effectively as possible, it makes sense not to disturb the team composition. It takes time to grow an effective team with the right culture, where members complement each other, where they feel safe and at home, and where they can excel.

Psychologist Bruce Tuckman described the different stages of group development. All of them are necessary and inevitable for a team to grow, face up to challenges, tackle problems, find solutions, plan work and be predictable in their output. When team members are regrouped, they need to go through these stages again, resulting in delay and reduction of output. This is another argument for keeping teams stable.

Move work

Unfortunately, teams are never stable. Employees get sick, leave the company and new people join. These life events are part of reality.

Also, in many organizations, team structures have grown historically and when scaling Agile practices, it may turn out that these structures are no longer sufficient. Teams experience a lot of obstacles and blockades that will keep them from being effective. Those that are organized around a system or component discover that they represent only a part of the customer journey. Consequently, they can’t deliver an end-to-end solution and take ownership of the product. When there are a lot of dependencies between teams, the planning becomes complicated.

Teams might manage to become effective on their own. However great this may seem, there’s a big risk that in doing so, they introduce local optimizations. For example, they only pull work items that fit their own purposes, like a mobile team selecting features for app development and a web team focusing on the website. When teams are unbalanced, this may lead to situations where one team is idly waiting for some bottlenecks to be resolved while, at the same time, another is working on items that match its purpose but are lower in value.

In one of the organizations I work with, we only recently realized this. After we improved the value determination of the backlog items, it became clear that the high-value items one team couldn’t commit to weren’t automatically picked up by the other teams. We tried to optimize the value flow and asked teams if they could drop one of their own items and replace it with an item that had more business value. Unfortunately, that didn’t work. Exchanging work items turned out to be ineffective due to a lack of experience and knowledge and because of bottlenecks created by the absence of specific functions within certain teams.

Move people

To reduce these bottlenecks, we have to consider changing the team composition. As much as we’d like to keep teams intact and stimulate the members to invest in their knowledge, when the imbalance persists, we have no other choice than to move people around. Organizations that want to optimize their value flow will need to restructure. They’ll have to create teams (or team clusters) that have autonomy, meaning that they can take ownership of their code and release their own solutions.

Reteaming, as Heidi Helfand calls changing the team composition, can be very beneficial for a company. Employees can learn from a different environment and seeing other parts of the organization. It offers a career perspective when they get to broaden their horizon and work with other teams or departments. Spreading people around the organization also boosts collaboration between teams. It’s better to work with someone you know and who knows your side of the story. Another nice side effect is that knowledge and experience get distributed across the organization. Moving people around might not only help retain and grow employees, but it can also contribute to better collaboration and a more unified way of working.

Reteaming might be a valid option when:

• the people involved embrace the change and see it as a chance to learn and grow as professionals;
• team structure is about to change anyway because the team is growing too big, new people are added or members are leaving;
• the teams involved aren’t yet effective or would benefit from a change in composition anyway;
• the receiving team doesn’t resist the change and welcomes the new members;
• the remaining team can compensate for the loss of teammates, either because it has enough knowledge and skills left to do the job or because it can do without the skills (or train people for them);
• the working methods in the receiving team don’t differ much and onboarding can be done effectively;
• the development efforts will be concentrated on those products where the profit is highest, and this situation seems stable;
• the expected value of the additionally completed work covers the time and money the teams will spend on switching and learning.

Move teams

Similar local optimizations can be found across department boundaries. Does a deadline for a major release justify a transfer of development capacity to that project? When a lot of money is being made within one division, should development capacity not be aligned?

Rather than relocating people, we can of course also move entire teams around. Again, this seems only logical when the new work is structural and there’s enough to do for the whole team. It might be wise to assess whether the additional team disrupts the department and introduces inter-team tensions or unwanted competition. When the team can pick up new work without too many starting problems, it’s something to consider.