5 communications techniques to get the best out of your offshore development teams

Medical Technology, Healthcare & Government IT

.
Categories
Category Groups

Netspective has been working on healthcare IT and medical device integration software for about a decade and has a extensive experience with outsourced and offshore teams. On our two recent unrelated projects I had the opportunity to work with two different offshore teams located in southern Indian peninsula. Both teams were well qualified in using the required development software and were able to successfully support the project needs.

In general both teams were comprised of experienced leads and many other hard working individual contributors. The leads demonstrated good knowledge of software engineering principles and appeared to be experts at the technologies they were using. I noticed that if the leads did not have an existing solution or needed to include a new technology or concept they were good enough to research and come back with good applicable solutions to meet the requirements. I also noticed that individual contributors on the team were very hard working, picked up any new technologies quickly and adapted well to developing the solutions for our clients. Given these qualities I understand that the offshore development teams never say “no” to a request made of them.

On this side of the ocean our management team is always looking to increase our effectiveness, to benefit our clients, by leveraging the skills of our offshore engineering team partners. Most of the time, the offshore development team has surprised me with their ability to deliver quickly. Since we use Agile development methodology (ref: Netspective Software Development Process Overview) on the projects we have used the following techniques to improve communication and delivery capabilities of our offshore partners:

  1. Holding requirements review meetings and requesting the development team to document their understanding of what needs to be accomplished. We request our development partners to provide a document that compiles the requirements that need to be met, modules they need to develop and associated test scenarios. This allows the development team to assume ownership easily as our senior architect helps improve their understanding by providing business scenarios to clarify the requirements. [ref: Module Design Document Template]
  2. Holding daily development progress meetings and to resolve any issues that the team may be running against. Agile development requires that our architects and project managers attend these meetings regularly to clear any development path obstacles. After experimenting with late night meetings we are now switching to early morning meetings in the US. At critical project milestones we meet with the development team at both ends of their workday. We use either a paid service from http://www.gotomeeting.com or a combination of available free tools like http://www.skype.com for voice calls and https://join.me/ for screen sharing during these meetings. There are pros and cons to both options which are beyond the scope of this article.
  3. Capturing minutes of all meetings so that onshore and offshore teams can stay in sync with each other without losing any decisions made in such meetings. It is important that the offshore team also takes the responsibility of documenting the minutes since you want to make sure that they are getting the message correctly and understand the actions expected of them. [ref: Daily Meeting Minutes Template]
  4. Using a project management tool to record action items as tasks and assigning tickets to appropriate team members for accountability. We use ActiveCollab (http://www.activecollab.com/) to manage our projects and for document collaboration in addition to client billing details. You must ensure that all assignments are assigned to individuals for proper accountability. Attaching the developers name to individual assignments has improved delivery on most occasions.
  5. Review, review, and review the developed system and code frequently. Our mantra is seeing is believing.

 

I am interested in hearing your experiences, good or bad, working with offshore teams and your project outcomes where you have used an offshore development team.

Original Link

Leave a Reply