5 tips for working with offshore teams

Recorded at Lean Agile Manchester on 21st June 2017
Dominic Torrisi: 5 tips for working with offshore teams


What I’m going to talk about, as Ian said, five tips for working in offshore teams. I’m a development manager at a company called RM, RM Education. Probably a lot of you haven’t heard of us. Background of RM, if you mention to people of a certain age, that’s what they’ll know about. Back in the day, used to make hardware. Now mainly focus on software and services. We do software for schools, produce the league tables for the Government, that kind of thing.

I’ve been there for about 10 years. Working with … We’ve got about five offices, but one of our offices is in Kerala in India so where a lot of our development is based. The way we’re structured, we still have some technical knowledge in the UK but a lot of our development is done out there.

Okay, so where to start? I’ll start off with tip one is around communication. I think, initially, I think first thing is about getting the basics right. The amount of times you join a standup, a retrospective, someone’s headset’s not working, someone hasn’t got the software installed, you don’t know what their Skype ID is, those kind of things. It’s really worth getting all those things sorted, making sure there’s a really good level playing field. Everyone communicate with each other easily. It just makes such a difference.

Some of the other aspects around that, so time zone makes a big difference as well, certainly in terms of how you communicate. As I say, our office is in India. They’re a mixture of four and half, five and half hours ahead depending on what time of year it is. That affects how you communicate things. If you’re working on particular pieces of work, you’ve got to be aware that sometimes you need to plan ahead. You don’t have the luxury of when you’re in the same office as your developers where you can just, say, they can come over and have a word with you if you’ve not given them all the detail. Sometimes you’ve got to plan ahead and those kind of things.

Tip number two about cultural differences. Again, I don’t think this is just about offshore. This is just about working with remote teams. It could be a team in another office in the UK, could be somewhere abroad. It’s people do things differently, people behave differently and you’ve got to be aware of that. You’ve got to be aware sometimes you’ve got to give people time and opportunities to speak, might not always be so willing to step forward. I’ve worked with a lot of developers in the UK who can be a bit gobby sometimes, whereas not everyone is, so looking at how you can do that. How you structure your retrospectives and things like that, and give people the opportunity to step forward.

Other cultural differences, sometimes people don’t like giving bad news. Quite often, you could be in a position where, in the early stages, a lot of people are saying, ‘Yes. It can be done.’ No one wants to be the person that says, ‘No. I don’t think we can do this.’ Sometimes you need to be aware of those kind of things.

Tip three, ownership. I think this is quite a key one, in that I think if you’re working with an offshore remote team, you’ve got to give them ownership of what they’re doing. You may ask why? I’ve seen this where it’s been done badly, where almost you’ve got a UK team and they’re drip feeding work out to remote offices and only giving them little bits to work on, and not really giving the full ownership of what they need to deliver. Quite often that just fails. People don’t feel ownership of what they’re doing.

Great examples where I’ve seen UK teams where, as I say, keep the cream of the work for themselves. Then, they’ll farm off doing the installers to a remote office or something like that and don’t really give them opportunity to own that work and succeed. Like I say, I think that’s something that’s really key is that you give people that opportunity. They can own it end-to-end.

Tip four, tools and processes. As I say, I’ve been working with offshore teams for about 10 years. When we started, wasn’t a great deal out there or there certainly wasn’t in our office. We were ferrying Word documents around with bits of specs in via email. We were using SharePoint, we were using Wikis here and there. It wasn’t very structured. That can work fine if you’re all in the same place and obviously using things like Kanban boards, great if you’re all in the same place. When you’re not, tools become a lot more important, I think, being well to have that consistent view of things across different places.

We spent a long time finding the right tooling for ourselves, and the same with process. We went through a lot of iterations. We started off, as a lot of people were many years ago, mainly Waterfall. Gav will do bits of Agile, gave Scrum a go. Took certain aspects of that away and moved more to Kanban now. As part of that process, our tooling has changed. We went through using quite traditional project management tools through things like Trello, so that we had basic boards, and then onto things like now we use Kanbanize. Then, we use a combination of online tools and boards, physical boards, in office. In the UK, I have a portfolio board which covers a number of different teams. In our other offices, we’ll have individual team boards. All of those are synced with what we’ve got online. That’s great.

Another point around process which, again, I think is key is getting people onboard. It can be all too easy to … You can be there in one office and you can be there telling everyone else, ‘Right. We’re going to adopt this new process.’ You can almost hear them sighing, going, ‘Oh not another new process.’ You don’t feel like you’re necessarily getting the buy-in that you want. I think it’s really key when you do anything around process, and Ian can speak from personal experience. When was that? Was it two years ago now?

Three years ago. We went out to our office in India. We took the team through Kanban. Went through setting up boards in the office and really trying to focus on getting everyone onboard and really understand why we were taking this approach. They really understood what we were doing, and it wasn’t just a case of, ‘Oh. Here’s another process that we’ve got to follow.’

Number five, relationships. That’s from a few years ago. Relationships are key really, aren’t they, to all of this. You can have all the process and everything. If you haven’t got the relationships in place, it’s difficult. I think there’s so much you can do around developing that. It’s really about getting to personally know people, so whether it’s going out as much as you can to your other offices, bringing people back to your office and that can be at all levels.

One thing that we do quite commonly is graduates will go out to our Indian office, spend three months there, work amongst the team, get to understand how it works in there. Get to build some relationships with people, that really helps. The same with the more senior people, get that opportunity to go out there and build relationships. Like I say, there’s probably a couple of people on there that no longer work at RM and I’m still in touch with them, keep in touch with them as friends. I think that really makes a difference because it really gives you the opportunity to … When you do have that physical barrier and you know you’re relying on Skype and things like that, I think knowing people really makes a difference in that position, I think. I think that was it.

Further information...

The content of this article is just the tip of the iceburg. To dive deeper into any of these case studies or concepts join our 2 day Portfolio Kanban live online course.

Application for a free Agile Coaching session

I would like to speak with an advisor