When a software project is outsourced or offshored to a faraway land, its obvious that it has gone through a very tough decision making process for the stakeholders of the company. When the decision is done you will find not everyone is equally happy. Especially the technical team is always bit reluctant. They have their reasons, starting from discomfort of working with people from different culture, to fear of losing importance in the company.
But in most cases this technical team is being asked to assess the outsource service provider and later work with them. This is a challenge other than the technical challenge itself, for the offsite team to gain trust and respect from the onsite team and successfully work together and deliver the project.
This challenge can be addressed though few core steps.
By building personal relationship
This one is the most important. Without a strong personal relationship with the onsite team most offsite effort
would ultimately fail. Even at the time of Skype and Hangout, I believe this personal relationship cannot be built with a strong foundation without visiting each other. Each project needs planning and budget which allows each team to visit the other with a regular interval. Its always a good idea to start a project onsite with a team combining onsite and offsite members and after one or two sprints break away.
By adopting the standards and tools of the OnSite team
If the onsite team has a set of standards regarding development which they follow, off-site team should adopt to those standards. Standards could vary from coding standards to development process standards, configuration management standards to quality standards. It good to use the tools used by the onsite team if they are habituated with it for long. It creates additional comfort for the onsite team having known tools in a new operating mode.
By introducing transparency
Its almost impossible to visualize what the other team is doing at any given moment if you do not have a transparent way to produce and deliver this information. Let the onsite team have access to off-site teams calendar, scrum board, burndown chart and issue tracker. Let the product owner of onsite team join your daily scrum, if not possible at least have a weekly meeting. Do the sprint demo in front of the whole onsite team over webex.
By addressing the pointing finger attitude
Pointing finger is a disease in every corporate house. When you see Onsite team is trying to burn you, the smartest way of handling the situation is to take responsibility proactively. Justifying the failure even with most strongest excuse mostly fires back. In case of a failure. always take responsibility, analyse the cause of the failure and propose concrete steps which can be taken to improve future delivery.
A reluctant onsite team can cause major project damage or even put the whole operation in jeopardy if program management from both side fails to find and act accordingly. Distributed development is not easy,it has its own challenges and like any other great challenges it has be dealt with open mind and brave heart.
But in most cases this technical team is being asked to assess the outsource service provider and later work with them. This is a challenge other than the technical challenge itself, for the offsite team to gain trust and respect from the onsite team and successfully work together and deliver the project.
This challenge can be addressed though few core steps.
By building personal relationship
This one is the most important. Without a strong personal relationship with the onsite team most offsite effort
 |
| Selise team challenges the onsite team |
By adopting the standards and tools of the OnSite team
If the onsite team has a set of standards regarding development which they follow, off-site team should adopt to those standards. Standards could vary from coding standards to development process standards, configuration management standards to quality standards. It good to use the tools used by the onsite team if they are habituated with it for long. It creates additional comfort for the onsite team having known tools in a new operating mode.
By introducing transparency
Its almost impossible to visualize what the other team is doing at any given moment if you do not have a transparent way to produce and deliver this information. Let the onsite team have access to off-site teams calendar, scrum board, burndown chart and issue tracker. Let the product owner of onsite team join your daily scrum, if not possible at least have a weekly meeting. Do the sprint demo in front of the whole onsite team over webex.
By addressing the pointing finger attitude
Pointing finger is a disease in every corporate house. When you see Onsite team is trying to burn you, the smartest way of handling the situation is to take responsibility proactively. Justifying the failure even with most strongest excuse mostly fires back. In case of a failure. always take responsibility, analyse the cause of the failure and propose concrete steps which can be taken to improve future delivery.
A reluctant onsite team can cause major project damage or even put the whole operation in jeopardy if program management from both side fails to find and act accordingly. Distributed development is not easy,it has its own challenges and like any other great challenges it has be dealt with open mind and brave heart.
