Derk-Jan de Grood is an Agile coach at Squerist. He accompanies organizations on their Agile journey.

28 September

Agile is a strong champion of stable teams. This might lead to local optimizations, though. Organizations that look beyond teams often want to shuffle the resources across teams or even departments. Derk-Jan de Grood discusses when this is beneficial.

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 squirrel or nut

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.


Device lifecycle management for fleets of IoT devices

Microchip gives insight on device management, what exactly is it, how to implement it and how to roll over the device management during the roll out phase when the products are in the field. Read more. .

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.

The waves of Agile
“The waves of Agile – Value delivery in medium and large organizations” by Derk-Jan de Grood is available at Techwatch Books as a printed paperback and a digital e-book.

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:

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.

Edited by Nieke Roos