Originally published on the Intersog Blog
Our approach to building the offshore team was to treat it as a partnership. The goal from day one was to have the offshore team become an extension of our US based development team. We had two locations on the east coast and the plan was to have the Ukraine team essentially be a third office and operate as part of the team. We followed Scrum as our development methodology.
We had approximately 15 team members in the US and added about 20 people in Ukraine in the span of about 3 months. We added developers, QA, Business Systems Analysts and Proxy Product Owners. After onboarding and initial ramp up of the new team members we divided the team into 5 separate Scrum teams. The majority of the teams consisted of both US and Ukraine team members. We focused a lot of effort on integrating the teams through the use of skype, video conference rooms and IM. We conducted daily standups with video and had frequent interaction between US and Ukraine team members.
The biggest challenges we faced were at the beginning of the project. These challenges were related more to the fact we brought on so many people in such a short time rather than the offshore aspect of the relationship. We faced challenges with knowledge transfer and ramp up while trying to still deliver code and meet project deadlines. This challenge would have been similar even if we had brought on resources in the US. Most of our team spent their first one or two months on the job in the US working side by side with the US based team. This helped with ramp up and knowledge transfer while establishing relationships with team members which was key to the culture we were trying to establish.
There were a number of challenges that were related to the offshore nature of the relationship. First and foremost was the time difference. It was more of an adjustment for the US team since the Ukraine team was used to this type of working environment. We made a few small adjustments which helped with the time difference. We had all team members add a second timezone to their Outlook calendars so it was clear when scheduling meetings what time it was in Ukraine. We also asked that any meetings with only US team members take place after 1pm in order to maximize availability for working together with the Ukraine team. Communication can be an issue as well. We were involved in the hiring process and conducted a video interview after our outsource partner did the initial screening of candidates. English proficiency was a key requirement for us given how we intended to integrate the teams.
Using Scrum was a goal of the project. The US team had been using an informal version of Scrum and the Ukraine team had various levels of exposure to it. We engaged Agile coaches to help the teams learn the process and understand best practices. We also conducted a sprint where we took a team with representatives from all disciplines (development, qa, business systems analysis) and all locations and worked on defining a Scrum process that worked best for the team and our distributed nature. Using tools such as JIRA and Confluence and other Atlassian products gave us a solid foundation for working in an Agile fashion.
I think the cultural similarities between Ukraine and the US contributed to creating a successful team. In general the team members got along well and there were no significant challenges related to cultural that would have been different in an all US based team. Conflicts did occasionally arise but those were more due to personalities than anything else.
Speaking about the skills, I found the skill level of our Ukraine team to be on par with that of our US based team. We had a team made up of Senior, Mid and Junior level people. I received positive feedback from managers and tech leads regarding the skill sets of the UA team. Prior to engaging with our offshore partner we had tried to hire US based developers and had a hard time finding what we were looking for at acceptable prices. A lot of that had to do with our US locations as well as the competitiveness of the US technology market. It took longer than expected to fill all of our development positions in Ukraine do to market competition there as well. We also had a few team members that didn’t work out but all in all I was very pleased with the level of expertise.
If I had to rank all of our development team, it would be a mixed list with US and UA team members throughout. We were working on older applications with some older technology so in a lot of cases both US and UA team members were unfamiliar and had to come up to speed.
When I’m asked about the recipe for successful cross-border collaboration I usually answer that the key to building a successful offshore/distributed development team is to embrace it as a partnership. Treat the team the same as you would full time onshore employees and seek to build a team that matches your corporate culture. We had a lot of engagement with the offshore team. In my role I regularly met with the Director of Delivery in UA via skype to assess where we were with the team and the projects. My managers oversaw the day to day activities of the offshore team the same as they did the onshore team. That approach enabled the offshore team to really feel they were a part of the team and in turn they showed a high level of engagement and ownership in the project. They put in extra hours as needed without even being asked. The emphasis on communication and the use of video also helped create a more cohesive team. That’s not to say there weren’t issues and everything went smoothly. There definitely were challenges that had to be worked through and overcome. The project itself had numerous challenges. But by focusing on a team approach where everyone was an equal member I feel we mitigated many of the challenges normally associated with using offshore development teams.
