We understand how to swarm around a feature as a collocated team. But how do you do that when you are part of a geographically distributed agile team? It depends on how you are distributed and across how many time zones.
How are you distributed?
Too many geographically distributed teams are separated by function. That is, the developers, or some of the developers are in several locations, and the testers or some of the testers are in other locations. The product owner/customer is in another location, and if the team has access to business analysts, those people are often in yet another location.
It's easiest to illustrate this with a story. I met a program manager, Stefan, in one of my workshops. He was based in Germany. He was worried about one of the projects in his program. That project had two developers in the UK, one developer in France, two developers in Germany, and two testers in Bangalore. The product owner was in Germany, and the product owner was also attempting to manage the backlog for two other teams.
There is plenty wrong with this picture. But his story typifies what I hear time and time again from geographically distributed teams. And, because the teams don't swarm around features, the Product Owner thinks he has time to multitask among several teams.
Focus the Effort
The first suggestion Stephan made was that the developers reduce their Work in Progress, their WIP, and they all focus on a single story at the same time. Previously, each of them had started on their own stories. Now, they all discussed, “How can we start on one story together?”
Start an Experiment as a Pair
They didn’t all start together. First, the two developers in the UK started together. They decided that since they were in the same time zone, they would start together. It made sense for them to start with the least time zone disruption.
The two UK developers were not physically collocated, so they had the same issues as any geographically distributed team. They tried a combination of Google docs, sharing screens, pairing, and working through the architecture. They had to practice with several stories. They learned that their stories originally were too large. When they made their stories smaller, it was easier to swarm.
Add in One More Developer
After the two UK developers practiced on one story, they were ready to bring in another developer. For the next story, it made sense to add one of the German developers. The three of them had a one-hour time zone problem to manage, as well as different start and end times for office and lunch hours.
They worked on and delivered that story, and decided they were ready to add a tester. But they were concerned about the time zone differences.
Add a Tester
With Manchester and London in the UK, Munich in Germany, and Bangalore in India, the project team was distributed over four and half hours of time zones. What’s worse they had a maximum of five hours of time together during the workday, assuming the tester stayed late, and the developers delayed lunch. While people might do that once in a while, that’s not sustainable.
So, instead of trying to work together the entire five hours, the team decided to separate their time into specific timeboxes.
Work in Timeboxes
We already know the value of working in timeboxes—that’s much of what agile is all about. But we don’t have to just work in one- or two-week timeboxes. We can work in smaller timeboxes, too.
This team decided to use the power of the timebox to focus their efforts during their swarm, so they could make the most of their time together.
For the first 90-minutes they swarm. The developers and tester worked together, sharing screens, pairing long distance, everything you can imagine as a collocated team.
Beyond the initial timebox, it depends on what’s going on for each person.
Can people synchronize their lunches? Or, do they lose the rest of the afternoon to lunch? The team has to sort that one out. This team tried several approaches, depending on what else was going on.
Manual Testing Slowed the Team
When they first started swarming, the tester was only capable of manual testing. That meant that the team incurred technical debt every iteration and that the tester never quite understood what was going on. When the tester worked with the developers, the tester understood what the feature did, but was still unable to develop the automated tests.
With swarming, the developers were able to build the hooks into the code for the tester to automate some of the tests. It wasn’t a perfect solution, but almost nothing is.
With coaching, the tester became less afraid of automation, and started to contribute more productively.
Add Kanban to Visualize Progress
Because this team had members in so many time zones, and had so little overlap, the team members used a kanban board to see the progress of all the stories. That way, a team member could choose whether or not to come in early or stay late the following day.
In geographically distributed teams, it’s common for team members to time shift. Not everyone will time shift every day, but if you can see that you can help the team by shifting an hour or two for a day or two, you might decide to do so, if you can. Kanban can help the team see whether or not this is worthwhile.
This team soon realized that as they started to swarm more often, they needed to time shift in order to swarm. They were too far away from each other to swarm easily, if they wanted to integrate the testers.
“We Need More Stories!”
One of the effects of swarming was that the team completed their work faster. Because they had less WIP, they finished their stories faster. They now put pressure on the product owner to provide well-written and smaller stories that they could swarm over. The product owner was surprised and was not ready for the team to be pulling work from him.
At first, the Product Owner tried to manage the need for all the stories himself. Then, he realized he was multitasking among all the projects. He asked for help and handed off the work for the other two teams to another Product Owner and concentrated on this team.
You Have More Alternatives
There are more alternatives to swarming than this team’s choice. If you decide to experiment, you might choose another way. This team chose this way:
- Start with whomever is closest.
- Add in the next person.
- Timebox to accommodate the timezone challenges.
Another alternative might be:
- Start with someone in each architectural layer plus a tester.
- Timebox to accommodate the timezone challenges.
Another alternative might be:
- Use a kanban board to visualize the work.
- Don’t try to swarm in realtime, but be available if someone has questions.
I don’t like the third alternative because it invites multitasking.
When You Are Too Distributed to Swarm Together
Sometimes, you are too distributed to swarm together as a cross-functional team. I see this most often as in my colleague Tim’s project. Tim has developers in several areas in the US: Cambridge, MA, Denver, and San Jose. All of the testers are in Pune. Because of the time zones, there is no easy time for them to have a meeting, never mind for them to work together for an extended period.
On Tim’s project, the developers swarmed together in their day. After they swarmed, completing their unit and integration tests, they handed off their code to the testers in Pune.
This is not ideal. However, they did use a kanban board to track the progress of the story and issues around the story. So, when the Pune testers had problems, they created cards on the kanban board that the developers could see and respond to.
Swarming across time and space is difficult. If you use tools that allow you to see each other’s workspace, that helps. But, what really helps is seeing the work in progress.
Swarming helps reduce the team’s WIP, which helps the team accomplish its work faster and better. It helps you see where you are headed. It helps build relationships among the team members.
And, sometimes, you just can’t make it work. So, don’t do it. But, if you have a chance, do experiment and see what happens. Do let me know what the results of your experiment are, okay?
© 2012 Johanna Rothman. This article originally appeared on InfoQ.