Agile teams often benefit from stability, but this isn't always the best approach. While stable teams enhance collaboration and productivity, they can also lead to isolated work and knowledge hoarding. Restructuring teams can offer advantages like employee growth, improved knowledge sharing, and better alignment with organizational goals. Ultimately, the decision to keep teams stable or shuffle members depends on specific project needs and desired outcomes.
Organizations that embrace agile principles often 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 job as effectively as possible, it makes sense not to disturb the team composition. It takes time to grow an effective team that has the right culture and where the members complement each other. A team where members feel safe and at home will excel. Psychologist Bruce Tuckman described the stages of group development that results in effective teams:
- Forming – getting to know each other
- Storming – figuring out how to work together effectively
- Norming – codifying team processes and practices
- Performing – accelerating productivity as the team hits its stride
- Adjourning – ramp down when a team is finished with a project or product
These phases are considered necessary and inevitable for a team to grow, overcome challenges, solve problems, plan effectively, and deliver consistent results. When team members are regrouped, they need to go through these phases again. This results in delay and reduction of output. So keeping teams stable often makes logical sense. But there are also compelling reasons to switch teams up in certain circumstances, as described below.
Support Staff Growth and Organizational Improvements
Teams are actually never stable. Employers get sick, team members leave the company, and new employees join. These life events are part of reality. When a team's composition is already changing, it's an opportunity to consider additional changes that can benefit the organization.
Team members benefit from changing environments and seeing other parts of the organization. Staff members gain fresh career perspectives when they have the opportunity to expand their horizons and collaborate with different teams. Spreading people around the organization will also boost collaboration between teams. It’s usually more productive to work with someone you know and who knows your side of the story.
Another nice side-effect of moving people around is that knowledge and experience get distributed throughout the organization. So moving people might not only help to retain and grow employees but also contribute to better collaboration and a more unified way of working.
Realignment for Autonomy and Ownership
In many organizations, team structures will evolve. When scaling agile for larger interconnected efforts, it becomes clear that initial team structures are no longer sufficient.
Teams that must interoperate experience a lot of obstacles and blockades that will keep them from being effective. When teams are organized around a specific system or component, they often discover that they represent only a part of the customer journey and cannot deliver end customer value. Some teams also have a lot of dependencies on other teams which makes planning and coordination complicated.
While maintaining team stability is desirable, organizations seeking to optimize value flow often need to restructure teams to enhance coordination. Ideally create ‘teams of teams’ (or team clusters) that have autonomy within the product or product portfolio they work. Autonomy allows teams to take ownership of their code and own the end-to-end delivery process.
The Risk of Local Optimization
Teams that manage to become effective can deliver value and are predictable in their output. Although that may seem fantastic from a distance, upon a second glance it may reveal a risk: local optimizations by the teams.
Teams often work only on items that match their purpose, for example a mobile team selects features to support mobile app development, while the web team focuses on features for the website. When teams are unbalanced or in different stages of group development, one team may be idle waiting for results from another team. For instance, the web team front-end developers may be waiting for database changes or testing to finish. Or perhaps one team is working on items that are less of a priority than other items sitting in another team’s backlog.
With one of the organizations I work with, we recently became aware of this issue. After we improved the way we determine the value of the backlog items within our cluster, it became apparent that high-value items that the one team couldn’t commit to, were not automatically picked up by the other teams. We tried to optimize the value flow and asked teams if they could drop one of their items and replace it with an item that had more business value. But that didn’t work. Lack of experience and knowledge made it difficult to exchange items between the teams. The lack of specific functions within certain teams created bottlenecks that made it ineffective to move the work items to the other team.
Moving People to Other Departments
When we look across departmental boundaries, we might find additional localization risks. 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 moving people, we can of course also move entire teams around. Again, to do this seems only logical when the new work is structural and there is enough work for the whole team. It might be wise to assess whether the new team disrupts the department and introduces inter-team tension or unwanted competition. But when the new team can pick up the new work without too many problems, this might be an option to consider.
Destabilize to Eliminate the Bottlenecks
The above bottlenecks can be reduced when we change the team composition by moving people around. Yes, it may be preferable to keep teams intact and stimulate that team-members invest in their knowledge. But when bottlenecks appear, consider restructuring your teams and move a few people around.
Although this might seem controversial, it might be productive when the following conditions are met:
- People embrace a change and see it as a chance to learn and grow.
- Team structure is about to change anyway either because the team is growing too big, newly hired people are added to teams or team members are leaving.
- Original teams and targeted teams are not yet effective as a team and benefit from losing old or welcoming new members.
- The receiving team does not resist, and the new members are welcome.
- The remaining team can compensate for the loss of their teammates. There is enough knowledge and skills with the remaining team to do the job. The originating team or department can do without (or train people for) the lack of unique skills.
- Working methods in the new team do not differ much from the original team and onboarding the new members can be done effectively.
- Development efforts will be concentrated on those products where the profit is highest, and this situation seems stable.
- Expected value of the newly completed work covers the time the teams will spend on learning and switching time/cost are covered.
- The organization needs to spread best practices and knowledge across teams for long-term success.
