Distributed Agile Approaches Optimize for the Team over Individuals

Summary: Consider how your team currently organizes: for resource efficiency, optimizing for the individual; or for flow efficiency, optimizing for the team? Successful agile teams—distributed or not—should collaborate to optimize the flow of work through the team. This approach lets you understand your capacity, learn together, and deliver more effectively.

Too many “teams” feel like a loose connection of individuals. Team members don’t affiliate with the team or the team’s goal. Sometimes they feel they must do other work in addition to their team’s work to help someone else outside the team. Now spread those individuals across locations or time zones and the affiliation becomes further diluted.

Instead of optimizing for people (resource efficiency), the team and managers need to change how they think and optimize for the team (flow efficiency).

Whose Goal Is It, Anyway?

The Search team was new to their agile approach. The team members were dispersed across North America, with a person each in Toronto, Boston, Calgary, Denver, Seattle, and Vancouver. To make it easy for you to envision the team, we’re using each person’s location instead of their names. They had a minimum of four hours of overlap every working day.

While they had a project goal, some of the people still had individual goals in addition to their project work.

Boston’s manager wanted her to learn the platform part of the search in order to achieve her specific yearly objectives.

Calgary’s manager asked that she coach other teams as a visitor. She wasn’t supposed to integrate with the other teams, but to help them find ways to finish their work.

Denver’s manager had made promises to other people across the organization, so Denver had to finish other work whenever he had a “chance.”

Seattle’s goals included supporting products that the Search team didn’t support. He’d been the lead developer on those products in the past.

You may have seen these kinds of problems in collocated teams. Collocated teams might find times to work together despite resource-efficiency thinking, or optimizing for individuals.

But when we use resource-efficiency thinking in distributed teams, we might not see the fact that people are not “allocated” to the team; they are “allocated” to their manager.

The farther apart people are in space and time, the more tempting it is for the team member and their managers to default to resource-efficiency thinking and actions. When this happens, the team members don’t have a single common goal.

They focus on work that only matches their skills, neglecting the common goal of delivering feature-based value.

This impacts team members and managers alike. Without a connection to a common goal or each other, team members disconnect, or unaffiliate, and become a group of strangers instead.

If the team and the managers can agree on a common team goal, the team can use flow efficiency. And when people think about optimizing for the team, they can deliver more value.

Focus on the Team’s Goal to Affiliate Your Team

The Search team barely affiliated as a team. They worked as a group of individuals. Much of their non-team work was invisible to each other.

To address this, they first decided to create a board with all their work, even if it wasn’t their team’s Search work. What they found surprised them. Only the people in Toronto and Vancouver didn’t have “extra” work. They were the only team members able to focus on the team’s work.

They knew about resource efficiency and flow efficiency. As a team, they decided to focus on affiliation for flow efficiency. They tried these experiments:

  • Continue to make everyone’s work transparent on their team board
  • Show their various managers all the work they had to do to be a successful Search team
  • Ask each other for help to finish their individual work

They used flow efficiency to encourage team affiliation and team goals. For a while, their team goal was “Finish all this work!” After a few weeks, they were able to focus on the Search project goals.

If this team didn’t have a particular goal, they might have a different story. People feel pressure to show their productivity when there is no clear team project goal, or when they feel discouraged from affiliating with the team.

In addition, the farther away a person works from their manager, the more pressure they might feel to provide updates on the work over actually completing the work.

Think of the Team as One Unit

Resource efficiency in distributed teams can prevent a team from delivering anything.

Resource-efficiency thinking breaks team collaboration and delivery because it breaks team goals and affiliation. Flow efficiency encourages team collaboration and delivery because it focuses on team goals and affiliation.

With flow efficiency, the team operates as a single unit. The team creates and focuses on one team goal. They collaborate to learn. They affiliate to manage their work in progress (WIP). The team can then deliver value and collaborate with customers for fast feedback.

The Search team first had to consider themselves as one unit. Once they did, they could then visualize and manage their work together.

Transition to Flow Efficiency

Resource efficiency might be ingrained in your culture. If so, consider the smallest experiments you can try. For example, if you need visitors to your team, consider mobbing around the visitor’s work. If your team doesn’t feel comfortable mobbing, consider pairing.

If your team currently assigns work based on everyone’s expertise, consider pairing (even at a distance) so the team has less WIP and everyone learns about the other kinds of expertise.

If one of your team members has specific learning objectives, see if you can integrate those objectives for the entire team.

Flow efficiency works better for any agile team, collocated or distributed. And when teams work in flow as one unit, they often see ways to collaborate and deliver better.

The Search team—and their managers—learned a lot once they saw themselves as one unit.

Once the Search team created a board where they could see their flow, they understood their real capacity.

The managers realized that their requests pulled the team away from the necessary work. The managers started to work across the organization to make sure they defined and prioritized the business needs. The managers then worked with the product owner to understand how to meet these needs. Then, the team could work on one business need at a time.

The Search team was able to see and then reduce their cycle time. Because they delivered faster than other people expected, the Search team was able to take more of a variety of work into their team.

When the Search team optimized for their team, they learned together and delivered together.

Mark Kilby and I wrote this article together. It was originally published on Agileconnection.com

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.