For some years we’ve been using business partners who are located offsite, often in different countries and timezones however our own development teams have always been based together. This is now changing …

For the past few months we’ve been working with scrum teams who are based in the UK, the US, Eastern Europe and Latin America. In general it’s been a great success but we have certainly learnt things along the way and I thought it would be useful to share these experiences. We used Martin Fowler’s model as a starting point for our own system and this proved to be very effective. We adopted pretty much all of Martin’s recommendations and I would highly recommend his article to anyone looking to implement their own distributed agile model.

Firstly let’s look at our logical team structure:

As can be seen, we use functional teams with component guardians providing the technical oversight of the application tiers. From a geographic perspective we have product owners based in the UK and US, architects and scrum masters based in the UK, US, Argentina and Estonia and scrum teams in the UK, Argentina and Estonia. Support elements are largely based in the UK and US.

We spent a fair amount of time working out the best geographic team distribution but in the end we came to one conclusion:

Timezone is the most important factor, everything else can be overcome

As a refinement of that broad statement we can say that product owners and scrum masters must be in the same timezone as their respective scrum teams, however none of them need to be situated in the same physical office. This gave us a logical structure – UK based product owners would work with scrum teams in Estonia (only a 2 hour difference) and US product owners would work with teams in Argentina (again only a 2 hour difference). We then had to decide whether to situate scrum masters with the scrum teams or with the product owner. On balance we found it better to situate them with the product owner because technical people were able to collaborate online easier than non-technical people.

Make full use of online tools

Technology has evolved so much over the past years that it’s now possible to do pretty much everything online in a collaborate environment. Some specific tools that are worthy of mention include:

Skype – Probably the most useful tool we use, being able to talk to people face to face has really revolutionized the way we work. Skype has also allowed us to build a social community across borders … we can point the webcam out of the window to show other team members the horrible weather, or the not so horrible girl walking outside.

Atlassian tools – We’ve used JIRA for some time but we’ve recently adopted the other Atlassian tools (Greenhopper, Confluence, Fisheye, Crucible) – There was certainly a learning curve, especially for Greenhopper which does not directly map to scrum in the way VersionOne does for example. It was worth the effort though because we now keep everything online. I was never a great fan of post it notes (being a tidy person) but Greenhopper seems to give us the same flexibility with more control

GoToMeeting/Webex - Being able to share a screen proved useful for technical and non-technical people. The product owners were able to illustrate things whilst the technies could adopt a pseudo pair-programming approach – they would share their computers and ask someone else to look at a problem they were facing.

Amazon web services – One challenge we faced was where to situate our development and test servers, how could we offer a small team in Argentina the same infrastructure as our much larger UK team? The solution was to allow teams (even individual developers) to spin up servers as and when needed.  AWS allowed us to offer a full performance test infrastructure to every team involved in the project.  It also helped to overcome the head office/regional office mentality in which developers in the head office can get “special treatment” from the engineering guys who are based alongside them.

What else did we learn?

• Don’t rely on email – It’s very easy to slip into long email threads which become unmanageable, we also found that people were hesitant to ask questions which they thought may have been answered in a previous email. They would spend 15 minutes searching through their email history and if they did find the answer it was often out of date.  Much better to ping someone on IM “can I ask you someting?” then call them using Skype
• Watch IM – chat can be addictive but in our experience it’s not as effective as a call … most people can talk quicker than they type and IM is inherently asynchronous – you can’t interrupt someone when all you see is “Dave is typing …”
• Share your screen, don’t check in bad code – Developers were often tempted to check in unfinished code so they could share it with their colleagues. Although source control should be used for collaboration it’s not a dumping ground.  Screen sharing was the answer
• Keep an online calendar showing key dates including public holidays – Initially we were caught out when a guy in the US would sit waiting on information from someone in Argentina, not realizing it was a public holiday. Google calendar works well for this purpose