Having a team co-located is the dream.
It’s proven to make any team higher performing, more successful, more efficient and with stronger relationships.
It stands to reason that to have a question come up, and to be able to turn around, tap someone on the shoulder, ask it, have a quick discussion and come to a resolution in just a few minutes is more efficient than having to type it on an email and wait 16 hours to get a reply from someone in a different time zone.
To be able to look at someones body language and pick up that they are not their usual energetic self, allows you to have a conversation that you’d not be able to if you’ve never laid eyes on them.
Being able to peer review a colleagues code and discuss it while looking at the same screen and sharing a keyboard, creates a deeper understanding and discussion than sitting on your own and adding comments to a spreadsheet would.
As such it would make sense for it to always be the case that teams would be co-located- right?
Unfortunately not. For mostly financial reasons, there’s a significant amount of distributed teams in the corporate world. It’s cheaper to have three developers in Pune for the same cost as one in the UK, so some think that this must make more sense and mean you can triple your output for the same cost. But ask anyone who has worked with both co-located and distributed teams and they will tell you the same story.
Can it work? Of course it can.
Can you still have a high performing team split across multiple time zones and countries? Absolutely.
Does it take a shit load more time and effort than having a team in the same room? Hell yes.
Does it create more muda (primarily waste due to waiting)? Totes.
Would you prefer to work with people in the same location? Every. Single. Time.
I love this graphic. It shows that with distributed teams you can succeed, but for those in distant locations you’re actually more likely to fail.
I had a question from a former colleague recently asking for some guidance on how to deal with a brain numbing 15 person stand up being done each day over via a conference call, which triggered these ramblings. So, here’s a bunch of things that I’ve found that can help if you find yourself working with a distributed team.
Create as many communication options as possible – set up a shared group channel on an instant messaging platform, instal web cams, and pick up the damn phone more than you ever have before. Email should always be the last option. Only use this if there is no alternative.
Respect local traditions – for example it’s the norm in Pune for everyone to take a lunch break at the same time, normally between 12:00 – 1:00pm, which is around 9:30 – 10:30am UK time. One you know about your colleagues routines and culture, you can then arrange meetings like daily stand-ups to be at a time that works best for everyone.
Start from a position of trust – assume everyone is willing to work together and is capable of doing the work to a high standard, rather than expecting the worst. If you start with some inherent negativity or hesitation, this will come out in different ways and biases and slow the process down even more.
Find the right tools – to make the work visible, know the status of it, understand who’s working on it. There’s plenty of tools out there Trello, Rally, JIRA, TFS etc… No-one should have to wait to find out the status of a piece of work – they should have a way of instantly finding out. Even planning poker has an online version so that a distributed team can still play this.
Invite and empower the team – to share information, to ask questions, to get to know each other, to collaborate
Agree on common standards and processes – it shouldn’t be one location ‘telling’ another what to do or how to do it, this should emerge and be agreed from within the whole system
Local optimisation – if you have small groups in each of 3 locations, have them sit together, have mini stand-ups each day, do social events and become a solid, cohesive ‘mini-team within a team’
Plan ahead – share meeting agendas prior to the start time, ensure the team have questions ready for group discussions, keep the tools up to date with the latest status and information. Even for retrospectives, they can be more fruitful by having a distributed team prep some of the work up front, especially around the story of the iteration.
Make the most of the cross over in time zones – you may only have 3 hours where everyone is in the office at the same time so make the most of this. It may feel like you’re squeezing in a lot of meetings each day, but that’s a consequence of not being able to have as many ad-hoc discussions. Also consider some flex in the working hours – can a team in one location start an hour earlier, and the people in the other finish an hour later to gain more cross over?
Relentlessly pursue what works best – when faced with the challenge of a distributed team, the inspect and adapt feedback loop applies to both the software product being built, but more to the way of working for the team. You need to constantly seek efficiencies and reduction of waste wherever possible.
Be patient – I want to re-iterate that you absolutely can have a high performing distributed team, however it takes a lot more time and conscious effort to achieve than a co-located one. If you really want it to work, keep plugging away, but don’t try to rush it, just keep showing up with the positive intention and eventually it will start to click.
Hope this helps, but if you have specific questions or scenarios that you want to discuss, just ping me an email. I’d love to learn and talk about your particular scenario or experiences.
What else have you found that works well for distributed teams?