Sunday, 13 January 2008

Home-shoring, Near-shoring, and Off-shoring - tips for technical leads with distributed development teams

First of all, a bit of definition - I define home-shoring as developers who are probably freelancers working from home as part of a geographically distributed team. Near-shoring is developers who are within a couple of hours of your timezone, and off-shoring is developers who are further afield. This blog post is NOT about Outsourcing.

I've been managing and delivering software projects successfully using distributed teams for 5 years now. I've managed distributed teams from UK, Romania, North India (Deli), South India (Trevandum), and China (Beijing) on various types and sizes of projects. On the flip-side, I've been a developer in distributed teams on several projects, working remotely from my home in the UK and one project in particular where it was being run from Spain. With this experience I offer the following tips to other technical leads who may already be working with, or considering working with distributed teams from home or abroad.
  • Make sure all team members can contact each other at all times. As a manager I insist all team members appear online and can be contacted instantly via VOIP. Very invasive yes, but I can walk up to team members if they're based in my office location so it shouldn't be any different for remote workers.
  • Use Skype or an Instant Messenger application to see when other team members are online. Verbal communication is very important, don't let language barriers stop you from speaking.
  • It's very unwise (or even suicidal) to attempt a project using a distributed team without adequate source control. One other tip whilst on the subject of source control - locate the source repository closer to the physical location of the majority of developers. I saw a company once with the source repository in the UK but all their developers were in India?!
  • Use continuous integration - along with automated testing as much as possible. Ensure all developers are on the email list for when the build breaks.
  • Ensure all developers check in code regularly.
  • Invest some time at project inception on training all the team on how to work together effectively. Show them the desktop sharing tools, show them how to use Skype properly, make sure they understand the source control system and the automated build. You can do this easily using Webex or other conferencing / collaboration tools.
  • If you can, realign the working hours of the developers to synchronise the timezones. In other words, get the on-shore team to work early's and the off-shore team to work lates. It's important to maximise the amount of true collaborative working time to ease communication.
  • Give all team members a proper brief. See my earlier post on how to brief developers properly. Once you've written a work package, send it to the remote developer. Give them at least half a day to digest it. The next step is to do a desktop share and verbally step through the work package with them, line by line. During this desktop share session you'll flush out most of the questions and answers. Once they start development on the work package, make sure you review their progress every day via desktop share, reviewing their code and looking at the working software on their PC.
  • Here's some tools that I use with remote teams - Lotus Sametime Unyte, Webex, Skype. Actually, one of the coolest tools I've seen recently is MPK20 from Sun Microsystems. I'm not sure how effective it will be for remote teams but I can't wait to try it out on my next project!
  • If possible, bring the off-shore developers over to spend the first two weeks of the project on-shore working along side other project team members. This will serve as an excellent induction to the project which they can then take back with them.
  • If you have a significant number of off-shore developers on your project, bring one of them over to your offices to act as technical liaison for the duration of the project.

I'm very keen to hear other peoples experiences of working with remote teams both as developers and as managers. Please post any comments on this topic so others can share your experiences.

No comments: