Offshore Development - Dream or nightmare?

I've been working doing offshore development for 5 years already. Through those years, I learned some really valuable lessons. In this post I will try to go over the benefits and problems it arises.
I will start with the first question you should ask yourself before considering offshoring.

Why do you want to do offshore development?
There could be many answers to this question. You could answer you are an NGO doing charity, giving people across the glove a good salary and a good life, because they are from a country with few opportunities. You could be an open source application and find a great committer in a remote location. You could say it's because you cannot find enough skilled people to do the work you need in your own country. But most of the cases it's just to cut costs. You want the same you get from a developer in your own country, but pay him a lot less. Even if it’s because you need to scale up and down as you need, offshoring is about cutting costs. People waiting until you want to scale up costs money too, same as scaling down when you don’t need them anymore. Yes, this does not sound idealist. It is not to make the world a better place. It's just to save money for wealthy rich people. Ok, I think I made the cost cutting idea clear. I'm not against cutting costs; actually I would love to be able to do the same with taxes. Now, this takes us to the second question you should ask yourself.

Do the savings justify all the hassle you get into by offshoring?
I would say it does. That's why many companies are offshoring right now, and more and more after the global crisis are trying to do it. Salaries of offshore developers range from 1/2 to 1/5 compared to developers in Europe or United States; this is depending on which country you offshore to. By just looking at initial numbers, it seems like it's the best deal of the world. Why wouldn't you save a lot of money on your overpaid IT salaries?  So far things had never been a dream with your local developers. That takes you to your third question.


What do I have to lose by offshoring?
The worst thing that could happen, it is to waste all the money you invest in the project. Normally, you will not get what you wanted. A very few times, you will get a decent application that meets your needs. You could also risk losing all your local people who knows about the application, the business and the project if you do no make them part of the bigger picture.  There is one thing for sure; many things will be more complex to do. If you are not able to overcome the increased complexity, you are more likely going to get something really different than what you ask for. Development will also take a lot more time than you initially thought it would.

Which things are more complex by offshoring?

The most complex thing is communication. Communication is not only about being able to talk over the phone in this case. It is being able to send a message, and that message being understood on the other side of the world. It’s not only about speaking the same language; it’s about being able to share the same language. If the team does not have a common language, everything else will be harder to share. By doing offshore development, you are already starting in disadvantage. The offshore team usually not only speaks a different language, they also haven't met personally the onsite members. If the team members are not able to leverage themselves by sharing their knowledge, then the distance between local and offshore will increase.

The time zone difference is also a factor that could complicate things. If you share most of your working hours with the offshore, you can consider them nearshore. If you shre little or none working hours with your offshore team, then you think about farshroe. Nearshore is simpler, and easier to manage compared when you do farshore.

If you want to do software development, you need to reduce as much as you can the differences between local and offshore teams. Reducing the differences will allow you to create a common language faster. First, think about one team, and not “them” and “us”. If you start it like this, you are already making differences. If you cannot trust your offshore team to do design, why would you trust them to implement your design? The more differences you are not reducing, the harder the communication gets. If you like lean software development, think about differences between local and remote teams as waste.

Culture is also a big difference to overcome. If you say “are you crazy?” some people could think they are doing everything wrong, when you actually wanted to tell them it is great. Some cultures also make people shy, because they are not able to freely express their feelings.  They reflect that on their work too, so you need to be twice the time more open to suggestions that you would normally do with people from your own country to get the desired effect. Again, building a common language is critical.

Which are the consequences of not having a common language?
The offshore team will go much slower and also going in wrong directions. Going in the wrong direction in software development makes the team work twice to get it back on track. This could mean your local team has to do this work because the offshore team will keep going in the wrong direction, or investing more time having your offshore doing it better. This could be the main cause offshoring your project could be more expensive than doing it right locally.

A lot of time will be wasted in communication to assure the offshore team understands what they need to do. This could mean endless meetings between local and offshore members discussing and trying to understand what is needed. If the team shares the same language communication time is reduced greatly and is more effective. Also endless meetings over the phone drive local and offshore teams crazy too. Nobody likes to be in a meeting over the phone for 6 hours, especially when it is in a different language. People get lost in the middle of the meeting. Details get more important than important things. Then you end up with your offshore team working on pointless details instead of things which add value to your business.

The offshore team will not be able to add value to the application. The offshore team only does improvements when they come from the local team as the direction to go. They do not know enough to improve things on their own, and communicate them effectively. Over time, any improvement attempt will stop, and they will only work on the requirements as they come. You need to get to the point where the offshore team is able to suggest and implement changes and fixes. If you are not at this point, you need to keep working on building a common language.

How do I build a common language?
The best way to build a common language, is to have your team interact. This does not mean talk over the phone, it means getting them to know each other. The best way to share things is by face to face contact. So the best thing is to get the team in the same place for some time and have them working together. This should be as mixed as possible, and aim to have everybody interacting with everybody as much as possible. Sometimes having the whole team traveling and staying onsite could be expensive. If you cannot afford it, then try to get onsite the offshore key players. They would be able to solve team differences faster when they are back at home. This also should not be once in a lifetime; bounds need to be reinforced periodically. This gives the offshore team a sense of belonging which is really important. If you don’t think you are part of something, you will hardly commit to it at a point where you make a difference.

Video conference is also very important, because it gives faces to the voices. It’s easier for a person to relate to another face than just to a voice on the phone or a signature on an email. It will help also to share the body language, which is sometimes as important as the words coming out from a mouth.

People on IT are known to be hard to deal with. They are not very eloquent, they do not have great acting skills; they are not best speakers. Why would you think it will be different in your case? If you do not invest on building a common language, the communication problem will be really hard to overcome. Initiatives will lose momentum right after they start making things harder to change the course of the project.

Is Offshore development a dream or a nightmare?
It will certainly not be a dream. It will allow you to reduce costs, making some projects possible. It will allow you to access really good development teams at an affordable price. If you are able to build a common language for the whole team, you will be able to reduce your costs considerably, and also be able to reduce the time things take to be developed. Building a common language is the most important thing when doing offshore, if you get to do it, you will get great results. If you omit this step in your offshore development, things will more likely turn into a nightmare.

As I said in the beginning, offshore is all about cutting costs but if you cut them too much, you will get the undesired effect. Frequent travels, reducing differences between local and offshore teams, video conferencing do make a difference when you build a common language. Not having a common language makes things take a lot longer, be more expensive and less likely to be what you expected.

Is it possible to do distributed Scrum or Agile software development?
I would not ask if it is possible, I think it is a must. As I said before, building a common language is all about the people interacting. Scrum and Agile, are in their roots about the same. Having daily short focused meetings allow people to build a common language. Visibility of project status and progress is clear, because you measure it with working software. Many practices from agile methodologies are of great help, such us continuous integration, testing, pair programming. These practices also help to build a common language, and reduce time spent trying to see which change broke everything since the last time the code was tested all together.

Waterfall is about interacting through documents. Documents are the worst way to build a common language. Documents hide differences, and they are often seen at the end, when you are already late to mitigate them. Maintaining documents is a tedious task and costs money too. You will also spend a lot of time on long meetings trying to explain what the document is about, instead of discussing what it's needed. Visibility of progress and project state becomes very fuzzy, I could send a document saying everything is about to be done, when it’s not close to it.

Conclusions
Doing offshore development is not only about the salary of your IT people. If you just look at that, you will only get the false perception of cost reduction. If you do not invest on building a common language, there are other things you will have to consider. Development will take longer than you initially thought. You will get a different product than you expected. Offshore development is not a dream or a nightmare. It is just like anything else, if you do it right, it will resemble a dream, if you do it wrong, it will be closer to a nightmare.