Presented by Jacques Labuschagne
[…]in order to attain the same communication “bandwidth” that a co-located team can achieve, distributed team members will incur additional time spent in team meetings with other remote team members. To facilitate the distributed teams, a set of tools and an environment to support the tools and teams will also need to be introduced and maintained.
—Monica Yap, Successful Distributed Agile Team Working Patterns.
Centralised teams and distributed teams are not so different.
Think about what makes a centralised team run well, and apply those principles to distributed teams.
The hive mind is shared knowledge, traditions, consensus.
The hive mind is connected by all forms of communication — conversation, email, IRC, documentation, …
People will communicate in the most convenient way.
Put them together in the same office and they'll default to spoken conversation, cutting out remote members.
Divert communication back along shared channels so that remote workers are not at a disadvantage.
Decided not to co-locate the Wellington team members.
Much easier for the locals, so stress phone conf etiquette.
Maybe try having everyone join by phone one day.
You need online tools — physical post-it notes are no good.
Set up a mail alias for the team and CC it on everything.
Don't answer questions in person; update the wiki.
“Work noisy”
It's always easier to disrupt things at the start.
If they have time to code, sound the alarm…
Should focus on policies, architecture, reviews, etc.
Team's interpretation of that output → QA for the Hive Mind.
* YMMV, might not make sense for small (1-2 dev) teams.
Workarounds: Set guidelines that empower. Make corrections after the fact.
A difference of more than half a day is a problem.
Workarounds: Minimize contention — try to keep story tasks within one TZ.
Maximize overlap — in extreme cases this could mean shifting working hours.
Holy grail: making timezones work for you — having issues fixed over night for QA to pick up in the morning.
Potential factors:
Workarounds: Boot Camp vs. Rotating Guru/Ambassador patterns.
People should be chatty on IRC, esp. early on.
Team members need to take responsibility for their participation — even more important for remote work.
Workarounds: Guidance, cajoling, careful team selection, trial periods.
What if my remote dev's office mates keep interrupting with “15 minute” queries?
Workarounds: negotiate 4-8hr chunks where that isn't allowed.
Distributed teams are more likely to also be large teams, and large teams have their own set of problems.
See also: Standups vs. Scrum of Scrums, dedicated sub-teams with improved autonomy.
open source technologists