How to make near/off shore work with agile.

Since May 2010 I have been working with agile development in combination with a near shore team in Ukraine so I guess I can say that I am somewhat experienced in managing distributed teams. All the issues encountered during these first two years have triggered me to write this post.

Ok, first of all to prevent myself from mentioning near shore and off shore development a zillion times in this post I will just refer to it as near shore development but everything applies to both.

Is Agile suitable for near shore development?

Many people working with agile methodologies always debate about the question if agile is suitable for near shore development teams. The real purists often comment that teams should be co located, which is of course the biggest problem when you work with near shore teams. And besides that, there are always numerous of small problems such as language, culture and time zone differences that make people doubt if a methodology that relies heavily on collaboration and communication, like agile methodologies do, can succeed in such an environment.

And because a lot of companies have problems to overcome the limitations that you run into when implementing agile with near shore teams the common way to work is the traditional waterfall approach where a company provides the team at the other location with a big design and then treats it as a magic black box hoping that some useful software will come out of it in the end (and the end is of course at least 6 months after the planned release date).

My mind set is just the other way around actually. In my opinion to make near shore development work you need to be agile. Agile methodologies give you more transparency in the progress and quality of the delivered work then any other software development approach. So if you don’t want your near shore team to be some magic back box that spits out random bits of software at unpredictable times, agile is the way to go.

Ok so the first hurdle is taken, we have decided that we need to do agile because we are working with near shore development and we don’t want to pour all our money in a black hole box. So what are the biggest issues that one needs to overcome to make agile succeed in working with near shore development? Well there are plenty of challenges. I have listed the ones that I encountered and are in my opinion most important for achieving success in these projects.

Create dispersed teams

When working with near shore development teams you of course have multiple options to organize your teams. If you have the possibility always create dispersed teams instead of distributed teams. Distributed teams are considered to be teams in a single location, but a different location than your main office. Dispersed teams are teams that consist of team members from multiple locations working together in a single team.

Why would you want this? It comes with a lot of problems regarding communication and aligning schedules. If you have employees in two different locations it would be a lot easier to create a team in one location and another team on the second location right?

Well it would indeed be the most logical solution, but trust me it is definitely not the best. There are several advantages in creating dispersed teams over distributed teams but the biggest advantages are transparency and improving communication.

A dispersed team forces communication between people in different locations. If you would create distributed teams, the people in the different locations will probably hardly communicate. Creating dispersed teams will result in more communication, which helps to lower the black box effect.

Dispersed teams also improve transparency of a project. When team members are working in different locations, all information regarding the project needs to be shared. This automatically provides a lot of insights in the project for everybody involved, regardless of the location in which they are working. If all the team members are working in a single location it will be difficult for people in one of the other locations of your organization to get a clear insight in the project. Since not all information will be automatically shared among locations.

What I find very interesting is the fact that current SCRUM purists often claim that SCRUM teams should be co located at all times. But in fact the very first SCRUM team was a dispersed team. When Jeff Sutherland started implementing practices that we now know as SCRUM he created dispersed teams with each team consisting of a number of people that were located in the US and a number of people located in Russia. So using agile methodologies in near shore development is not that strange to do.

Treat them as equals

A while ago I was talking to the CTO of a software development company in Holland that just started working with near shore development teams. When I asked him how they worked together with their near shore teams some interesting things came up.

Whenever there was an important decision to be made in one of the projects, the people in the headquarters would discuss the possible solutions and would make a decision, after that they would notify the near shore development team about the decision.

This is just one of the examples that CTO gave me during the short meeting that we had that indicated that the developers in their near shore team were not seen equal to the developers working at their headquarters.

If you are working with near shore development teams you will want the people in the near shore office to feel connected to your company. Only when employees feel a connection with the company that employs them, the employees will go that extra mile to complete their work.

Excluding the team in the near shore location from important decision is one of the worst things you can do. It will most certainly kill the morale of the people and will do even worse things to their creativity.

You should also strive for equality within the team in which your near shore employees are working. I have seen teams where the near shore members got all the nasty tasks that nobody wanted to do. This is definitely not what you want if you want everybody to put their best efforts in.

Learn their culture

When you are working with people in different countries keep in mind that there might be cultural differences between the people in your office and the people in the near shore location.

These cultural differences might seem small but could have a higher impact on the working process than expected. Cultural differences could be related on how people communicate with each other but also how they behave within an organizational structure.

For example in the Netherlands (where the company for which I am working is based) we are very used to flat hierarchies in organizations. This is not the case in all countries and this could effect the way people work together.

Cultural differences could be related to all kinds of aspects such as company culture, religion, men and women relationships, etc. So it is important to learn about and understand these cultural differences in order to take them into account.

Meet each other as much as possible

Mail, chat and video conference will mostly suffice for the basics in communication between the people in your office and the near shore team, but don’t try to save money on meeting each other in person.

Meet each other as often as possible. Visit them and let them visit your office. And when you do fly in some people from the near shore office to your office keep in mind that the people that are performing the work are most important. Too many times companies only let the project manager or accountmanager of their near shore teams come over to their office. If you want to build a wall between the people working in your office and the near shore team than this is the way to go.

Some companies go into the extreme with this and bring the team members from the different locations together for several months in a year. The more the better but of course  it depends on the budget you can make available for it.

Don’t forget about social communication

When working with development teams in a different location you are forced to communicate over e-mail, chat and conference calls. The disadvantage of this is that you miss out on the informal communication that you normally have with colleagues at the coffee machine, water cooler or during lunch.

The biggest pitfall therefore is that you only end up communicating with your near shored colleagues on work related things. It doesn’t hurt to ask how somebody is doing from time to time or how is wife and kids are and how his or her holiday was. This happens naturally between colleagues in a normal work environment, when working with near shore teams you will need to put some extra effort in this, but it will pay off.

Synchronize your watches

This might sound like a scene in some action movie were people synchronize the time on their watches before they dive into some secret high risk mission, but it actually applies to working with near shore development as well.

Most of the time when you work with near shore there probably will be a time zone difference between your country and the country of your near shore partner. Agile methodologies require a lot of communication between all the people that are involved in the process. Trying to do that when workdays are shifted between the different locations for more than one or two hours will make this impossible.

So you have two options here:

  1. Find a near shore partner that is close to your own time zone.
  2. Make an agreement with the people on both locations to adapt their working times to maximize collaboration with each other. But keep in mind that also in this case you should treat everybody as equals. So the adaption of working times should be a compromise on both sides, not just the team members at the near shore location adapting to your working times.

Appreciate them

Remember that your near shore team members are not computing units or cyborgs, they are humans too. Appreciate them and invest in them (time, education, experience) basically treat them as your own employees.

Conclusion

The conclusion was actually already mentioned at the start of this article: Yes agile methodologies are suitable for near shore development.

Will the advise from this blog post bring you instant success? No, but in my opinion it will help you to get the most of your near shore strategy.

So why would you want to put all this extra effort and time into working with near shore development if working with co located teams takes less effort? Usually near shore / off shore development is a strategic decision of an organization, and when an organization has chosen for it, middle management will need to figure out a way to work with it and get the best possible results.

Agile methodologies and (at least I think so) the small advises in this blog post will give you the tools to make near shore or off shore development work.

Tags: , , ,

Trackback from your site.

Leave a comment