Many enterprises these days are outsourcing software development to offshore teams. Your organisation may have even tried it as a way to get access to highly skilled resources cheaply, and scale development resources up and down as you need them.
But more often than not, I hear of project failures that are blamed on offshoring. People say things like: “The offshore developers just didn’t understand what we needed” or “They developed completely the wrong thing.”
So why is it so hard? The main cause for these types of problems is a failure in communication and lack of teamwork. This has been my experience as an Agile delivery manager and coach.
As an example, let’s take a typical software development project following Scrum (the most popular Agile framework) such as the deployment of a customised ERP system.
The entire team including developers, business analysts, testers and a product owner (who represents the business users) sit together in the same room.
The group should communicate informally and act like a team by following Scrum guidelines such as letting members choose their own tasks on a shared board, and ensuring everyone helps out to meet the bi-weekly (sprint) goals.
The product owner can easily illustrate requirements by writing something on the board or giving a quick verbal example. And when you do it right, Agile enables organisations to develop a solution that can change as the business requirements are adjusted.
It enables you to deliver a working solution to users within a couple months with only the highest priority features to start. Then the team re-aligns the solution by continuously communicating with the business (or product owner).
Now, take that same ERP deployment, but have the team based offshore. The team members have never met each other, are not all sitting together and do not have the same working hours.
Due to the lack of face-to-face communication, cultural differences and time zone issues, the developers start to misunderstand requirements. In an attempt to close the communication gap, the product owner starts to use more written communication, which causes more misunderstandings.
The next thing that happens is because the team has never met one another, the onshore developers don’t treat the offshore developers as part of the team.
The offshore developers start to work on their tasks independently, become less likely to clarify aspects of the project, and because they feel that they need to fend for themselves, they start to blame each other when something goes wrong.
In my experience, this lack of communication and teamwork leads to poor productivity and a solution that doesn’t provide value.
Make it work offshore
So how can you make Agile work with offshore developers? You need to get back that informal communication and teamwork that is there on a successful Agile team.
You need to overcome the issues that arise due to the fact that the team members have never met one another, are not all sitting together and do not have the same working hours.
All team members must be treated the same, and communicated with in the same manner, whether they are onshore or offshore.
Increase informal communication
In an Agile project, there is usually less written documentation and more face-to-face communication. The product owner verbally explains business value rather than giving the team detailed functional and technical requirements.
If the team understands the value of a requirement (or user story), then they are able to discuss alternative solution options. I believe this is one of the key things that can make an Agile project provide more value than a traditional project approach.
To get the entire team to communicate face-to-face more, I suggest using a ‘blended’ team. Rather than an entire outsourced team, a few offshore resources are embedded within the onshore development team.
The reason I’ve found that a blend of both onshore and offshore resources works well is it’s easier to ensure that requirements are communicated in an Agile manner (not just written down and handed over to the offshore team).
I was involved in one project where the product owner verbally explained requirements to the onshore developers and wrote down requirements for the offshore developers.
It was pretty clear that rather than trying to resolve communication issues, they were just trying to avoid them. Instead we put tools in place to ensure the product owner was able to easily communicate face-to-face with everyone consistently, in as simple a manner as possible.
Video conference is the closest thing to face-to-face communication with offshore team members. When coaching a team, I ensure that team members are talking to each other informally by video conference at least once a day real-time, during the overlapping working hours (instead of by email or instant messaging).
We used a ‘video wall’, where we had a large TV screen permanently on (using Skype or something similar). The entire offshore team sat together in one room so we could easily see everyone.
Onshore developers would walk over to the screen, say ‘hi’ and have a brief chat with the rest of the offshore team.
With Scrum, the team uses a task board to determine what needs to be accomplished in the sprint. Rather than a physical task board, we used an on-line tool to review and update the task board.
Offshore developers chose tasks themselves rather than having them assigned to them and everyone could see who was working on what. When issues arose, everyone pitched in to help out to ensure that all the tasks were complete.
Focus on teamwork
Everyone knows the benefits of teamwork in principle, but in practice it is much more difficult especially when part of the team is based offshore. There are a few methods I use to get everyone to work together towards the same sprint goals.
I have found that the only way people start helping each other out is if they feel like they really know the other team members, and understand what motivates them.
To encourage this kind of social interaction, we did a video conference chair race - India vs Australia. It was a fun way to get the team joking around with each other.
We also brought the offshore team members over to Australia for a few weeks. A little real face-to-face time went a long way.
I mentioned earlier that I believe if the team understands the business value behind a requirement (or user story), then they are able to discuss alternative functional and technical solutions and come up with what is best.
To make this work, all the team members must speak up and act like an equal member of the team.
Early in one of my projects, I found that the team was under-estimating the amount of development work and one of the offshore developers wasn’t able to deliver on time.
Our onshore designer was coming up with innovative user-friendly ideas but what I wanted the developers to do was discuss the designs as a team and come up with the best option that still fit within the timeframes we had.
To help resolve this issue, I asked one of the offshore developers to take a leadership role in the planning session and although he was to listen to the others for their input, it was up to him to give the estimates for the tasks.
The one caveat was that he then had to meet those estimates. This exercise seemed to give him the confidence to speak up much more in later planning sessions and act like an equal team member.
To make offshoring work with Agile, you need to overcome the communication and teamwork issues inherent in a team that have never met each other, are not all sitting together and do not have the same working hours.
Overcoming these issues is a challenge, but with the implementation of a ‘video wall’, an on-line task board, plus some coaching, you can still gain the benefits of Agile with a ‘blended’ team (mix of onshore and offshore developers).
Lorraine Pauls Longhurst is an agile coach who is an expert in offshoring software development to India. Email her at lorrainepauls@lplconsulting.com.au.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.