My first piece of advice is this:
DON’T DO IT!!!
Probably the worst possible setup for “team” is spreading them around the country or the world or the universe and expecting them to behave and deliver like a close, cohesive team.
My second bit of advice for those of you that blame it on “Management” and say you don’t have any say in the matter…is:
WRONG, YOU HAVE LOTS TO SAY IN SUSTAINING DISTRIBUTED TEAMS OR CREATING ANOTHER STRATEGY!!!
I hear this situation (excuse) all of the time. An organization has inherited distributed teams yet also wants to move to more agile approaches. They understand that these teams can be less than optimal, but are reluctant to do anything about it. That is but complain about it.
I recently read an article entitled Engineering Culture and Distributed Agile Teams that was published in InfoQ. In it, the editor called out the following strong themes or takeaways:
- Team structure reflects in product architecture
- Distributed teams can perform pair programming by using some remote pairing techniques and tools.
- Microservices influence a good distributed team structure
- Increase co-ordination within a team by encouraging T-shaped engineers
- DevOps tools and practices are valuable for Distributed Agile Teams
- Increase efficiency of Continuous Integration and automation testing in distributed teams by using cloud
While the article is titled and implies a focus on culture, it really focuses more on technical tactics or tooling as the key to distributed teams.