When a software project is outsourced to a land far, far away, it is obvious that the decision to do so was a tough one for the stakeholders of that company. Making the final call will inevitably result in a few despondent faces within the organization- especially the technical team. Always reluctant concerning such a move, technical teams have their fare share of reasons. This may range from the sheer discomfort of working with people from different cultures, to the fear of losing importance in your own company.
Interestingly enough, in most cases these companies would go to their technical team in the first place for the primary assessment of the outsource service provider. Not only that, these technical teams are the ones who would have to work with them in the future. Keeping the technical tidbits aside, this imminent friction presents as a challenge itself for the offsite team to gain trust and respect from the onsite team.
The successful delivery of any collaborative project may hinge on the onsite and offsite chemistry. This challenge, however, can be addressed through a few core steps:
This one is the most important. Without a strong personal relationship with the onsite team, most offsite effort would ultimately fail. Even with the advent of Skype and Hangout, I firmly believe that in order to build a foundation for such personal relationships, you must visit each other. Every project needs planning and budgeting, which should allow teams to visit its counterpart at regular intervals. It is always a good idea to start a project onsite with a team constituting of both onsite and offsite members. After one or two sprints, you can break away.
If the onsite team has a set of standards regarding development which they follow, the offsite team should also be ready to adopt to those standards. Such standards could entail coding standards, development process standards, configuration management standards, quality standards, and alike. I would also advise and go on to say to use the tools used by the onsite team, ones they are accustomed to. This creates additional comfort for the onsite team to have known tools in a new operating mode.
It is 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 offsite team’s calendar, scrum board, burndown chart and issue tracker. Let the product owner of onsite team join your daily scrum. If that is not possible, then at least have a weekly meeting so that everyone is on the same page. Do the sprint demo in front of the whole onsite team over WebEx. These little things will all contribute towards a far more transparent communication between the onsite and offsite teams!
Finger-pointing is a disease rampant in most corporate houses. When you see that the onsite team is trying to burn you, the smartest way of handling the situation is to take responsibility proactively. Even with the most strongest of excuses, trying to justify the failure almost always 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 damage to the project; even the whole operation could be in jeopardy if management from both side fails to act accordingly. Distributed development is not easy- it has its own challenges, and like any great challenges, it has to be dealt with an open mind and a brave heart.
Originally published in his blog: www.bangladeshinsoftware.com on June 2013