Thoughts on Distributed Agile Teams

I’m currently a member of a coaching circle and our topic last week was “Non co-located or distributed teams”. Then this week someone from our marketing department approached me. We’ve decided to bring our public website in-house and they need a new team, but history has shown us that finding new developers of the calibre we want is no easy feat. One option we haven’t explored to date is developers who work remotely (which would mean we could look farther afield) and he wanted to know what my opinions were. I offered to compile some information for him, including some of the conclusions from my coaching circle discussion, and then figured it was worth adding it to my blog too.

I have worked in distributed teams before – from formal project teams with developers on-site in Cape Town working with off-site analysts, testers and project managers in London; to informal ‘leadership’ teams across offices over three locations and two countries; to performance managing direct reports working in an office 2000 km away. The common point of success or failure every time? The people on the team. The next biggest point of frustration every time? The type and quality of communication tools available.

People

There is a lot of literature out there around the types of behaviours you want in agile team members and, obviously, each company also has its own set of values and culture it looks for in new hires. This list is a list of traits that stood out for me as things that made someone great to collaborate with when working in a distributed fashion. All too often, people without these traits made distributed collaboration quite difficult and sometimes impossible!

• Emotional maturity – able to communicate without getting emotional about things; can handle openness.
• Strong team norms – when the team agrees to try something or work in a particular way, this person will take accountability for whatever they have to do even if it wasn’t their preferred way of doing things
• Effective communication – verbal and written. Can write and read well. Can get their point across and summarise well.
• Takes responsibility for preparation – if things are distributed beforehand for people to read or prepare, then this work is done. Doesn’t walk into meetings “blind”.
• Knows how to use tools and knows about conference call etiquette (this could be covered as training for the whole team).
• Is proactive in staying ‘in the loop’ – will ask questions if they see something that they don’t know about (defaults to information gathering rather than assuming if it was important enough someone would let them know).
• A T-shaped person – or at least someone who is prepared to do tasks that are not ‘part of their job description’

 

Other Success Factors

This list was compiled by my coaching circle:

1. Face-to-face is necessary for initial trust building and to create coherence. Where possible, having everyone co-located for a period at the start of the project makes a huge difference. Also gets people used to the way others work without the ‘noise’ of not being co-located.
2. Would be helpful to find ways to have online virtual interaction (outside of work) e.g. online games/ice breakers/other experiences.
3. Face-to-face tools are a must.
4. After an extended period, it helps to have team members ‘rotate’ as traveling ambassadors.
5. Need to understand cultural differences. Probably worth having a facilitated session to highlight/understand these.
6. If you have teams working in areas, then have an on-site SM/coach per team.
7. Keep teams small.
8. Try pair/collaborate with an offsite person as often as possible.
9. If you have teams in different locations, have a dedicated facilitator in each location for meetings (like planning, review).

Links

• Some suggested best practices
• Here are some anti-patterns to look out for. I particularly liked the way any solutions were evaluated against the Agile Manifesto, which seems a great way to go about checking suggestions.
• Ideas for how to do remote pair programming
• Some pair programming tools
• This link has some suggestions on how to run distributed retrospectives and also lists some tools
• Added 29/02/2016: Double Robot – a cool way to work remotely

What has your experience been with working in or with distributed teams? What did and did not work for you?