LAS2013 Thoughts: Making Distributed Teams More Effective

More thoughts from Lean Agile Scotland 2013. A couple of guys working for Neo discussed common anti-patterns of distributed teams, and possible ways of addressing these.  The big risks are around fragmentation or isolation. This really resonated for me – with a team which is currently split across two continents, and has in the past had single satellite team members, I have definitely seen most of these.

Fragmentation: If you have two or more similar-sized groups, the risk is slightly different. Each group may bond as a team, but there’s not so much communication across the group boundaries so you effectively have two separate teams instead of one.

Isolation: If you have a core in one office with a few individuals elsewhere, the individuals may not get included in the general team-bonding chat/banter, may get fobbed off with the dirty/boring work, may effectively get excluded.

There’s a particular danger if you cross timezones. I think he spoke from personal experience on this, being a UK employee on a US team. They get up early to get work done, but they’re tired/fixing the build/… so they don’t make a huge amount of progress before the main team comes online.  And then they’re just closing down for the night at ten o’clock, and someone on the main team says “oh great – since you’re still around, would you mind looking at this for us. It could wait until tomorrow, but if you do it now we’d save a day…” End result – the remote worker doesn’t get to bed until after midnight, so they’re even more exhausted, and so the vicious cycle goes on. To protect against this, everyone needs awareness, and the main team should instead be saying “what are you doing still online now? It’s after ten pm where you are – go to bed!”

Things which can help forge a single cross-site team:

  • Get people together on one site – this builds relationships in a way you can’t do remotely. Either rotate people one way or the other, or all get together, or something. And plan to keep doing this.
  • Use video conferencing for multi-site meetings, and do this often (daily). It sounds trite, but it really does make a difference when you can see the others rather than just hearing them. I can speak from personal experience here – we’ve done this with our multi-continent team, and on the occasions when video fails it is much more impersonal and easy to fall into “them and us”.
  • Have team members on multiple sites working together on the same task. He suggested cross-site pairing, which does require good fast links, and works best with simple text editors rather than fancy graphics sharing. We have have good success in our team with a story which multiple developers from the two sites work on together. One developer takes the lead for the story and coordinates the work of the others. Our most successful development actually had 3 sites involved. They defined interfaces, and were constantly on IM discussing the next steps so they were all working on the same micro-feature next.
  • Have a shared informal chat forum where the team chat/banter can go on (as well as possibly specific technical forums).  This allows the bonding to be maintained.
  • Have very regular retrospectives so any problems and concerns get surfaced and discussed. Also public demonstrations of wins – each team member demonstrates what they’ve achieved when they finish something.
This entry was posted in Process. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s