Distributed Agile Teams

Replies to This Discussion

Permalink Reply by John Reber on February 3, 2010 at 16:07

Hi Kelly

I'm working on an agile project distributed over 4 timezones (US, UK, Russia and Singapore) with the UK as the hub.

Our use of tools is pretty basic - everyone is on IM, available on phone, offices remote access into presentations and meetings, everyone shares the project wiki, the incident tracker, and we have clocks on the wall so we're aware of common office hours. Beyond that we have not found specific technologies which we have considered would improve the communication process - I guess in this way we are abiding by the agile manifesto 'Individuals and interactions over processes and tools' even if we are contradicting the principle 'Face-to-face conversation is the best form of communication (co-location)' .

The tricky part for us is the time management issue of arranging story huddles, retrospectives, presentations etc during common office hours (obviously we can't get all 4 offices at the same time). It's not unusual for us to be sitting in a meeting with a number of laptops around the table displaying the seemingly disembodied heads of our US or Singapore colleagues. It's like being in an episode of Red Dwarf.

The biggest problems we have had are making sure our CI build is not red when Singapore/UK clock off for the day. We also have to ensure that the test environments are usable at the end of the day. It's the equivalent of leaving a tidy desk before going home.You have to put yourself in the mode of a 24 hour office. Or a tag team wrestler!

Also the non-hub teams need to be empowered enough to make on the spot decisions for those moments when the hub is not available otherwise valuable time is lost.

We try to arrange onshore and offshore visits, not practical for every project but it's invaluable in aiding the communication process and instilling confidence in our relationships.

If the distributed method is managed correctly then you can reap the benefits of 12-24 hours project effort everyday. It's challenging but I would recommend it even if some think it goes against the ethos of Agile.

• ▶ Reply

Permalink Reply by Kelly Waters on February 4, 2010 at 21:17

Hi John. Many thanks for your response. Sounds pretty challenging but sounds like you've got it working pretty well! Anyone else have stories to share on this - I think it would really help other people to know what others are doing to overcome this challenge in agile...

Kelly.

• ▶ Reply

Permalink Reply by Patrick on February 10, 2010 at 22:03

Hi Kelly,

I've run distributed agile projects for over 2 years now. I agree - nothing replaces face to face communication, but in this economy, travel and relocation funding is not as prevalent as years past. For the tool set, I always keep it simple: Agilo (including built in Wiki), IM, phone, SMS, GoToMeeting (or equivalent) and a white-boarding tool with pen and tablet for all team members to draw. I try to discourage any other "exotic" type tools as they tend to add complexity. I plan on working in Google Wave in the future, as I see some real benefits for that.

As for the challenges, I've found it can be difficult to build the personal connection and trust between distributed team members. To solve this, I always schedule face to face meetings at least once a quarter and ALWAYS at the project kickoff. My project members are always in the continental US, so this is pretty easy to accomplish.

I've actually found that the distributed nature has a very large advantage in that it requires you to be concise and focuses in your interaction with other team members and it has cut down on a lot of "side discussions" to a level that doesn't hinder team performance but allows for that personal interaction needed to build team comradely.

Cheers,
P

• ▶ Reply

Permalink Reply by Kelly Waters on February 10, 2010 at 22:11

Hi Patrick. Thanks for taking the time to share your experience. Sounds great! I always worry a bit when there isn't an opportunity for side discussions. Sometimes these are the conversations when you happen to find out important information that people forget to mention when they're not passing so often. I totally agree that it's not always financially practical to travel or relocate people. That's why it's so good to hear how people are overcoming the inevitable challenges of working collaboratively without being in the same place.

Thanks again!
Kelly.

• ▶ Reply

Permalink Reply by Perry Mizota on February 16, 2011 at 17:42

Hi Kelly,

 

We recently did a blog post on this exact topic.  You can check it out at http://teleplace.wordpress.com/2011/01/25/finding-a-place-for-distr....

 

Perry

Teleplace

• ▶ Reply

Permalink Reply by Kristine on March 3, 2011 at 16:40

Hi Kelly. 

We work with lots of companies that come across this issue, and after repeated questioning, one of our evangelists blogged on Agile with remote teams. Check it out- hopefully it can answer some questions!  http://www.accurev.com/blog/2010/07/15/agile-remote-teams/

 

Kristine

• ▶ Reply

Permalink Reply by Tim Ottinger on May 24, 2011 at 21:04

Here are a few tips for you.

http://agileinaflash.blogspot.com/2011/04/rules-for-distributed-tea...

• ▶ Reply

Permalink Reply by Sowmya on May 26, 2011 at 7:06

Hi Kelly,

     We have been practicing distributed agile for almost 5 years now. I certainly agree to the fact that co-location aids agile but being a software services provider.. distributed agile is inevitable. There are different ways to bridge this gap ..by way of emails, telecons, video conferencing,voice/video chat, blogs, wikis, collaboration tools, continuous integration and many more, but beyond these tools the way in which a team is distributed can aid/hamper agility.

1) In most projects we ensure that the Product owner is co-located with the business groups and the end users.

2) When team members are split across geographies then split of work happens based on the features

ex: Feature 1 - team in Sydney , Feature 2 &3 - team in Bangalore, Feature 4 - team in London

Try to avoid split  based on the tasks.

ex: Coding - team in Sydney, Testing - team in Bangalore, Design - team in London

3) Consider a person with a good functional knowledge of the application/domain as the scrum master and locate this person along with the team. If we do not have the luxury to have scrum masters for each distributed team , consider identifying a Proxy scrum master ( a person from within the  team can be groomed to play this role).

 

Hope it helps

-Sowmya

 

• ▶ Reply