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.

Agile, Chaos and Evolution

Let's get started with my simplified version of evolution. I'm not an expert on this, but Internet can turn any mortal with some time into anything.


Evolution in nature
Imagine you have a bunch of cells forming an organism. Each cell has a copy of the organism's DNA. The fitness measure how successful is an organism in its life, . The better the organism does during its life in the environment it is, the higher the fitness. A mutation is defined as cells having different DNA than the parent cells, due to a wrong copy of the DNA.

While the organism is in a stable environment, it will reach an equilibrium fitness value. When the organism is close to its equilibrium with the environment, the cells that mutate fast are suppressed, favoring the ones that mutate slowly.

A chaotic environment is defined as an environment that changes randomly and you can't predict it's future with certainty. It's also been seen that in a chaotic environment the organisms will favor the cells that mutate fast. Those will be picked by the organism in its effort to adapt to the environment. Once the organism starts adapting to the environment, fitness will stabilize, and the organism will go back to favor the less mutating cells.

Having too many mutations does not always mean the mutated cells will increase the organism fitness, it might take it to death too. Some mutations are good, and those should be the ones the organism needs to keep in order to survive to the chaotic environment. There is a cellular mechanism, which attempts to fix bad mutated DNA in order to prevent diseases and increase overall organism fitness.

Actually this is natural selection, the organisms who can adapt will survive more time, being able to reproduce more. While the ones with a lower fitness have lesser chances and time to reproduce, disappearing over time.

Some organism might found a perfect fitness for the current environment, conquering the world very fast. Later on there could be another environment change that could cause that particular organism, to quickly die, or other organism could mutate and feed from the previous organism. Perfect is enemy of good in this case. Perfect means everything is in order, everything works as it's supposed. If something is not in order or does not work, everything falls apart. While good searches for redundancy allowing the organism to survive if something does not work. It's better to be good at many things, than great at only one.

Evolution in software development
Now imagine your development team is the organism. The people in the team are the cells forming the organism. The organism DNA, which has been copied to each cell, is your development process. Each person has a specific copy of the DNA encoding. Management is the cellular mechanism in charge to control the cells do not mutate with the wrong copy of the DNA.


Predefined DNA
Some methodologies allow you to define the development process. This is similar to create a DNA for your organism. They let you know how the DNA should look like. You can make some changes, adapt it to your environment and use it to your organism. The person or team creating the DNA will attempt to create it perfectly. The DNA is in the organism before the cells that make it. If those cells cannot create an exact copy of the DNA, you need a strong cellular mechanism, to enforce the exact copy, or remove the bad cell of your organism, like a cancer.

Once you get into a chaotic environment, the cells will mutate at a faster rate, thus management will have more work to enforce the perfect copy of the DNA. This is because changing the DNA is expensive. It's expensive because it's complex and it was defined by a 3rd party. It takes more effort to change it than enforce it. The energy of the organism will be wasted on preventing mutations of all kind, reducing the ability of the organism to adapt to the changes in the environment.

Fitness is measured by achieving milestones in the schedule. In a chaotic environment those milestones have to change. You have to rework your project plan, your schedule, etc. to keep you milestones up to date. If you are not able to keep up, this causes wrong measurements of the fitness. Often the resulting fitness will only be seen at the end of the project, when it's probably too late to fix it.


Evolutionary DNA
Looking at Agile approaches I can see the DNA is not injected or defined by 3rd parties. It's grown from the cells in the organism. Each cell gives a piece of their DNA, to generate the organism DNA. The way to measure the fitness of the organism, is working production code at the end of the iteration. Once the iteration is done, the cells are able to improve the DNA causing mutations, exploring better alternatives to their particular environment. Once they get to their next iteration, they will be able to check if the mutation improved or reduced their overall fitness. The cellular mechanism should focus on preventing bad mutations, the ones that reduce overall fitness.

Agile methodologies only define a basic ceremony, which initially you need to follow, unless you are very confident of what you are doing. Once your team starts getting close to the equilibrium fitness, means everybody knows what they have to do, without have to introduce more changes in the DNA. This is the point where you will start favoring less mutating cells. This is the point where you want to get to, have a self organized team, which can react to the development needs.

Why Agile rules are so basic and simple? It is because they aim to set the most basic healthy DNA, from which you can evolve. Why it's so hard to implement them? This is because evolution is not easy. At first, all your cells will fight to make it to the organism DNA. You should start from the most basic healthy organism, and evolve to overcome the problems. Do not start from an advanced DNA, because it is complex to change, and you will end up with a powerful cellular mechanism to enforce it instead of focusing on evolving healthy.

Mutating the DNA and enforce it, is no longer a management task. Management can focus on avoiding bad mutations, which could cause diseases in the organism. This is not always easy, because there are a lot of cells in the universe which have a really twisted DNA. Starting from a wrong DNA, could turn your project into failure because you will need lots of iterations to get to a point where things start happening. If you do not have good cells in your team with healthy DNA, you need to invest precious time and money on training, and aim to maintain your good ones.


Healthy evolution
When you start from the basic organism, to evolve in the right path you need to focus on the basic agile principles:

-Focus on improving your fitness with continuous delivery of valuable working software for the customer.

-Focus on decoupled code to prepare your application for changes. Do not create your own internal framework to solve common problems because it increases the complexity when they are not common anymore.

-Focus on testing, to prevent new changes from breaking your application, reducing your fitness in the future.

-Focus on refactoring, change your code base to be simpler, better and avoid duplication. Learn and architect your application through this.

-Focus on having motivated and healthy cells, because that's what makes better the organism as a whole.

-Focus on interactions and knowledge share. If the cells do not know what to do, they will easily mutate in wrong DNA. This will also give you redundancy, allowing your organism to survive when it lost the head.

How Agile helps to evolution?
There are very important pieces in scrum that will allow and even force you to evolve. One of those is time-boxing. This is why you have time-boxed iterations. This is why all your meetings should be time-boxed. This is why you need to set a limit in the time you spend discussing issues. This is another factor that creates a needed amount chaos for the team to speed up evolution. If you couldn't get any production code at the end of your iteration, you need to evolve. If you couldn't get enough information from the users in the meeting to continue, you need to evolve. If you couldn't prioritize all the tasks you needed for the next iteration, you need to evolve. If all your team is locked waiting on the only person being able to do a task, you need to evolve.

You need to remove obstacles as fast as possible. This creates a better environment for the organism to evolve healthy. If your problems are not quickly overtaken, you team will mutate with wrong DNA in an attempt to continue with evolution, causing bad long term effect and diseases.

Have a small and well prioritized list of tasks to do next. Continuous big shifts in the direction of the project will accelerate mutations. This will create constant chaos, too many mutations and bad fitness measurements to ensure things are in the right path. You will end up with a bad DNA, and no compass to guide you in your evolution.

The team is what makes everything. If your cells are not healthy, they will make your organism sick. Fitness will be reduced, not because of wrong DNA, because the organism is sick. Aim to keep them happy. If you want your puppy to do all the tricks you want, you either need a big stick or bacon in your pocket. The big stick never works in IT, people leave their companies just because they don't like a framework the company is using, imagine if you scream at them. A good piece of bacon is what works. It does not mean overpay your employees, there are many ways to find out what would motivate them, spend time in this, it's important.

Why Agile does not solve my problems?
As I said before, Agile focused on the most basic healthy organism which you can start from and principles you have to follow to evolve healthy. It cannot impose a solution to all your problems, because it will not be able so solve others problems. If Agile would present a complex DNA for you to solve everything, you will not be able to change it and you would need again strong management to enforce it.

It's not paradise; you will get into many problems too. Where to go? What do I have to change to be better? You cannot keep changing everything in your DNA after each iteration. In the end, you will get nothing, even less than if you enforced any other more complex DNA.

If you solve problems you don't have, you are wasting energy from the organism in things that do not increase your fitness. Aim to solve the problems that reduce or prevent your fitness to be higher.

I said you need to evolve to overcome your problems. Sometimes the hardest thing is to realize what your problems are. If you don't know which your problems are, you need to spend more time reviewing the roots of those. If you are not able to deliver working code at the end of the iteration, aim to do the smallest thing possible, and grow from there. If testing of current code is impossible, aim to create code that can be tested, and decouple pieces as you can. Doing the simplest thing exposes your problems clearly. Doing complex things will easily hide them.

You know your problems, but they seem hard or impossible to solve. This case is simpler, try to waste as little as possible to overcome them. For this type of problems, seek help in Lean Software development principles.

Conclusion
Start from the most basic DNA and evolve to overcome problems. Do not start from complex solutions, or you will need strong management to enforce it, wasting energy. Aim to reduce waste from your organism. Aim to be healthy and do anything to increase your fitness; this is in the end, what will allow you to last longer.

sources:
http://www.obitko.com/tutorials/genetic-algorithms/index.php
http://www.talkorigins.org/faqs/evolution-definition.html
http://www.jstor.org/pss/3067634
http://evolution.berkeley.edu/evolibrary/home.php