In part one, we looked at some of the effects working in very different time zones might have on your working day, and at some of the communication challenges (such as long feedback loops) that you’ll need to manage. In this post we’ll look at some of the personal and cultural differences you might encounter.
It’s easy to feel separated from your team members or stakeholders even when you’re all based within the same building. Those of us who’ve worked with distributed teams have found communication with our off-site team members to be even more of a challenge, and this can contribute to a lack of engagement or feelings of separateness between team members, particularly if your development team are at a different site to the business.
One of the stories I was told involved a project manager based in another country to their development team, with a ~9 hour time difference. Unsurprisingly while this project manager felt responsible for delivery, they didn’t have the visibility they needed. To deal with this uncertainty they would often schedule progress meetings, and sometimes these took as much as two hours out of the working day. In this situation everyone would have been happier with a PM based with the development team.
Another colleague told me about an engagement working as a consultant for a large US Fortune 500 company, who wanted to use an offshore development team. The client was based on the East Coast and recruited a team in India. The client wasn’t able to integrate with the offshore team and tended to throw work over the fence to them, expecting finished product at the end of each sprint with little communication.
The client had engaged my colleague and other his peers because they recognised their teams’ skills needed improvement, and when it became clear that the Indian team also needed help they asked the consultants to travel to India to help the team there up-skill and become more familiar with agile development. However the consultants found they could not bridge the gap between the client and their supplier:
…there was such a disconnect between the teams I don’t believe the team in India could ever have delivered what the client wanted. There was a lack of communication from the US based team, and a lack of clarity of requirements.
Once senior management became aware that the Indian team weren’t strong, they recruited another offshore team and played the teams off against one another. Unfortunately this didn’t help to resolve the problems the project faced.
What Worked For Us:
Managing work between teams that do not share a working day is tough, and you’ll need to work even harder to build effective working relationships than with teams that share a similar working day. As I’ve mentioned before (1), doing everything you can to improve communication between your remote team members, regardless of their location, is key. In one of the examples in this post, a colleague flew out to India to spend time working with the supplier’s development team and found them to be far more engaged than the client’s own team; they wanted to learn and to deliver what the client wanted but were struggling because the client didn’t know how to work with them. This was a difficult project, but the consultants found that by spending time with the remote team they were at least able to build a good relationship between their companies.
Occasionally you might find that there’s little you can do to improve working arrangements, or to help a project deliver successfully, but this can provide a valuable personal learning opportunity. Learning how not to manage a distributed team and dealing with these problems first-hand can give you the confidence in later roles to either make sure your recommendations are taken on board, or to understand when it might be the right time for you to move on to your next role.
Working with an offshore supplier will be cheaper, right?
Cost-effectiveness was cited a couple of times as a reason for choosing to engage an offshore development team, and while this can be less expensive than hiring a full time, permanent employee in your local city, it’s important to consider the costs your project may incur if development takes longer because answers are slow to arrive, or if some of your team need to travel. Here’s an example: recently a colleague was working from the US and had to get to India. He was in the air for 19 hours, with two connections as well as transfers at each end. This sort of travel either takes a lot out of your weekend or the working week, and it takes a huge amount out of the budget.
I haven’t yet touched on the need to be culturally aware when you’re working with a remote team. When we were talking about the experiences the OpenCredo team have had working with distributed teams, we found there some interesting cultural differences we’d needed discovered along the way.
For instance, “Yes” can mean “Yes, we understand and we’ll try” in countries that tend towards formality or politeness like India, rather than “Yes, we promise to deliver X on date Y” which might be what the client chooses to hear. Some cultures will tend to over-report progress, whilst others will be more pessimistic, and it’s important to be aware of this difference, and on which side the team you’re working with is likely to fall. In the UK, we tend to avoid physical contact further than a brief, firm handshake and tend to underplay our strengths. In contrast, some of our team have found, working with people in the US, that they preferred a handshake with much closer physical proximity and might say something like “I’m John, and I work damn hard for my company”.
Organisational culture can differ too. Companies based in the US may have a concept of “casual time”, where staff receive share options but no pay for extra hours and feel a strong personal affiliation for their company. One example of this I heard while interviewing people for these posts was about the manager of a helpdesk based in California. He’d be at his desk at 6am each day in order to be available to the New York team at the start of their working day, and he’d stay until 6pm, which was the end of the day for the team in Hawaii, and was proud to be always available.
On the other hand, in Germany, the standard working day is 8am until 4pm, and (at least in some companies) if you’re still at your desk at 5pm you can expect a tap on the shoulder from your boss, who’ll wonder whether your workload is too heavy or you need more training. Working extra hours is seen as a sign of inefficiency or other problems there, not productivity.
Some cultural sensitivity towards your partners can help everyone build personal and professional relationships with one another, and might help both sides avoid offending each other, or becoming annoyed by behaviour that’s considered perfectly normal to the other party. Here’s another example – presenting a business card in parts of Asia can be part of a formal, ceremonial introduction. You would be expected to hold the card at the edges with your fingers and thumbs and offer it to the recipient from the centre of your body. However, in one meeting I heard about, a participant from the US arrived late, and quickly dished cards to those around the meeting table Las Vegas Dealer-style – to the horror of the other meeting attendees. Taking your jacket off in some companies in Germany is seen as sloppy or unprofessional, whereas in the UK we see taking off your jacket and rolling up your sleeves as a sign of getting stuck into work.
As we all become more accustomed to working with people from around the globe, we become more aware of, and perhaps less upset by, this sort of difference, but there are still so many little things you can get wrong that mean your relationship starts off on the wrong foot.
Share the same working day: If at all possible, work with teams that share the same time zone with you, or whose working day overlaps considerably with yours. Do everything you can to keep any feedback loops as short as possible.
Have your teams work on self-contained activities: If you can’t share the same working hours, then have your teams work as independently from one another as possible.
Don’t expect offshore development to be cheap: You may find that your overall costs are lower than if you hired an equivalent number of staff on site in London, for example. But don’t expect it to be a cheap option. You need to remember to budget for travel, communications and potentially training too, and should aim to build a long term partnership with your supplier, with solid personal and professional relationships, for your arrangement to be truly successful.
In the previous post we touched on what might happen if your management teams are operating separately to development, and in a future post I’ll look at agile across the enterprise, and how it involves more than the development team or those stakeholders working closest to them.
References & Further Reading
The Remote Works series at 37Signals, including http://37signals.com/svn/posts/3651-remote-works-bebanjo-spain
Woodward, E, Surdek, S and Ganis, M: “A Practical Guide to Distributed Scrum”, IBM Press, 2010.
Latest posts by Karen Rogers (see all)
- How To Get The Most From Your Scrum Master: Part Two - 20 January, 2015
- How to get the most from your Scrum Master: Part One - 28 February, 2014
- Cucumber Android vs Appium with cucumber jvm - 28 January, 2014