This is a guest post by Johanna Rothman.
More than half of all agile teams are not collocated—each person sitting within 30 meters of each person. If teams blindly use approaches that assume collocation, the teams might fail. To bypass failure, first, understand the kind of team you have and the data you might need to collect. That data will inform your team’s approach to agile practices.
We often hear people describe their teams as collocated, distributed, or dispersed. Unfortunately, too few people agree on the meaning of these words. And, even if you do have a non-collocated team, the type of team will drive the workflow and metrics you need.
Collocated Teams: How Close is Close Enough?
Your collocated team might sit in one room, a team room. A team room encourages people to work together, to swarm, pair, or mob as needed.
Too few teams have team rooms. However, the team members are sufficiently close to each other—within 15 – 30 meters of each other—that they can easily seek each other out to ask questions, collaborate when necessary, and decide what to do as a team.
It takes an adult about a second to walk a meter. So 15-30 meters is about 15 – 30 seconds. If all your team members are farther than that apart, you have a form of a distributed team.
When it takes longer than 30 seconds to ask a question, we tend to defer the question. That means we stay stuck on a problem, or worse, move to some other kind of work. We increase our WIP, Work In Progress. When we increase our WIP, we move fewer things to done ourselves, and as a team.
If your team members are distributed on one floor farther than a 30-second walk, you have a distributed team. Walking to someone on the same floor is much better than having to take the stairs or an elevator.
If your team members are on different floors—even in the same building—they are part of a distributed team.
In From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver, Mark Kilby and I offer ways to think about non-collocated teams: satellite, cluster, and nebula.
Satellite Teams: Bulk of Team Together, One or Two Apart
Satellite teams have most of the team members inside a 15-30 meter space. One or two other people feel as if they “rotate” around the bulk of the team.
We see this a lot when the developers and product owner are in one office and the tester is either on another floor, in another office, or even in another country.
Satellite teams appear to work in “cliques.” Because the collocated team members work together on a daily basis, they share information as a collocated team does. Too often, they forget to share information with the people who aren’t there.
Out of sight really can be out of mind.
Sometimes, the team members cluster in offices or locations. That’s the cluster team.
Cluster Team: Team Members Work in Twos and Threes
Sometimes, we see the developers together in one space, the testers together in a different space and farther than 30 meters from the developers, and the product owner might be on another floor.
In this case, the developers are one cluster, the testers are another cluster, and the product owner is a satellite. We still call this team a cluster team.
Your team might be a cluster if the people who sit near each other represent different functions. The key is that some people cluster together, and other people cluster in a different location.
Cluster teams tend to be more aware of their tendency to become a clique. They often find ways to collaborate to see the work move across the board.
There’s a third kind of team, the dispersed or nebula team.
Nebula Teams: Everyone is Dispersed from Everyone Else
If everyone on your team works from their house or a coffee shop, your team is dispersed. Maybe everyone is in a separate office from everyone else. Whatever the location, each team member is farther than 15-30 meters apart.
When everyone is separate from everyone else, the team has less tendency to develop cliques. On the other hand, it might be much more difficult to collaborate on the work and move it to done.
Nebula teams have a significant positive: they know they need to create a virtual workspace that everyone has equal access to.
See Your Distributed Team’s Reality
Regardless of the type of team you have, consider treating the team as if it is a nebula team. Make sure everyone has access to all the code, tests, and tools the team needs.
Create a board that maps the flow of work through the team. When I work with non-collocated teams, I ask them to map their value stream. Who initiates the work? Who takes the work next? What do they do with that work? When does the work stall, in a wait state?
After the team maps the flow of their work, I ask them to add up their cycle time. Cycle time is the amount of time the work stays in the various working states plus the time the work stays in the wait states.
Once the team sees its value stream and measures its cycle time, they can ask these questions:
- Is everyone on the team affiliated only with this team, or does other work pull them away?
- Is everyone on the team capable of accessing all the team’s workspace: code, tests, meeting tools, whatever the team needs to do its work?
- What would we have to do to create more collaboration opportunities?
Your team might have other questions based on the value stream map and the work in progress on the board.
Solve Your Team’s Problems
Many distributed teams have long cycle times and too much WIP. The first step to a solution might be to create a board and limit the team’s WIP.
When teams limit their WIP, they start to see the various problems with their team. In my work with distributed teams, I often see these problems:
- Team members don’t affiliate with the team. They affiliate with their manager.
- The team doesn’t have sufficient infrastructure to collaborate.
- The team doesn’t have sufficient hours of overlap to collaborate.
My recommendations are to first identify your team type. Do you have a team type that supports the work you want to complete?
Next, map the value stream and measure your team’s cycle time. See how the work flows through your team and how long it takes your team to finish work in the form of value to a user.
Finally, start assessing your team’s collaboration possibilities.
Once you know all that, your team can decide how to create a successful agile project.
This article was written by Johanna Rothman. Johanna, known as the “Pragmatic Manager,” provides frank advice for your tough problems. Her most recent book is “Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.”
