Building an offshore team with agile

One question that I receive more frequently is how agile software development works with an offshore team. I get this questions from either people already doing agile and thinking of building out a team, or those that are very much involved in outsourcing and are thinking of crossing to the dark side of agile.

The short answer is that yes it can be done and that it should be done but it comes with some conditions. I have implemented this type of a model numerous times. Below is the list of considerations that I’ve learned on the way.

Time Overlap
Make sure that you have at least two hours overlap for your teams to be able to communicate in real time. This greatly improves information exchange and builds cohesiveness of the team. Depending on your time zone this consideration alone may dictate where to build your team. Some locations simply don’t provided for the needed overlap.

Short sprints
Fail fast, fail early is one of the agile fundamental principles. By having your sprints one or two weeks you can see progress quickly and take corrective actions when needed.

Concentrate work by location
If you have multiple scrum teams try to organize them by location. Have a full local team and another one remote. This provides for a better communication. If you have no choice and have your team spread over multiple locations do not break by skills. Do not set it up so you have developers on one side and testers on another. Have all roles represented in each location to allow teams to function independently.

Keep your scrum master local
At all costs keep a scrum master together with your team. Scrum master is an enabler of the team. Putting them in a remote location imposes unnecessary delays and complications.

Define “Done”
A product owners must clearly define ‘done’ criteria. Inability to constantly communicate requires remote teams to function on their own. Not having understanding goals clearly will lead to conflicts and mistrust.

Have a strong leader at each office
You must have a strong leader at every location. Each team must feel enabled to move forward and make things happened.

Web and Video conferencing
Use of video conferencing creates a sense of proximity of team members. In today’s day these tools are free or nearly free. For example we use Google Hangouts for every team that are open all day long and people can just drop in and out. This way people who are remote can see what’s going on in the other office, they actually overhear conversations as they are happening. This creates for a very productive atmosphere.

Data Repository
Create an easily accessible data repository and collaboration site. There are plenty of tools available that make this affordable. My personal tool of choice is Confluence because of how well it integrates with Jira. SharePoint will also serve this need if you are running in a Windows environment.

Invest in training
Your remote team must be proficient in scrum or whatever agile methodology you use. Invest in traveling to the remote team and training them. It’s is worth the cost.

Email usage
Do not use email as a primary method of discussions and decision making. Also don’t use email to store product documentation. Use person-to-person communication to make decision and store all the information in your data sharing repository. This makes it searchable, accessible, and trackable. Email is still a great tool, but it shouldn’t be the only or primary communication tool.

Leave A Comment...


The reCAPTCHA verification period has expired. Please reload the page.