My last few projects have involved large-ish (up to 50 or so) teams, spread across multiple locations. I’ve been reading about this, and had the occasional conversation with @seldo about how NPM runs its teams, and I’ve realized a few things.
Firstly – language is crucial. Invest in a common idiom!
But the business domain is where the real benefits are – making sure the team (and the client) all share the same language is always important (Evans’ Domain Driven Design emphasis this too), but with a distributed team, it’s crucial. I spent about half a day on Slack with a developer in a far-away land trying to work out how to reproduce a bug the client had logged – it turned out all 3 of us had a slightly different interpretation of “product” on the ecommerce site. You can work that out in 5 minutes face-to-face, but at a distance, this can become a huge time-sink.
The second issue is – ridiculously – audio quality. One of our offices has beautiful high ceilings, and stylishly sparse decor in some of the meeting rooms – as a result, the audio quality on audio conferencing is terrible. We’ve got great speakers from Jabra which help – but it’s really worth investing in the best quality audio kit when using Hangouts for a Scrum.
The third issue is a little more subtle. It’s a culture thing – and I’m not sure I always get this balance right. Especially when working remotely, it’s really important that developers get “workable” assignments – a clearly described problem to solve. If it’s a development task, the story/task/whatever should be ready for development – all the dependencies should be clear, the task should have enough requirement detail to allow the developer to work on it. If it’s a bug, there need to be clear steps to reproduce the bug, expected and actual behaviours etc. This is hard to achieve with a remote team – backlog grooming, sprint planning etc. is hard to do remotely, and we tend to use a more centralized model, with a small group of developers and managers assessing and assigning work. Some developers enjoy this – “I just want to code, give me my todo list and don’t bother me”. Others want to be part of the process, and feel ownership of their piece of work. It takes a while to find the balance here – but I’ve learnt to hire “heads-down, coding” people alongside developers who are more engaged in the process.