-
We’re learning something about remote work during last year. I work for a software company that uses SCRUM and we have team members at our office in São Paulo (Brazil) and a small team that works at home in different cities.
We use these tools:
- github - our source code repositories are hosted at github and we use Pull Request feature for Code Review.
- grove.io - for “watercooling chat”. Grove basically provides a web interface and a limited IRC interface. grove.io keep loggings for chat rooms and implement some integrations with github. We make some tests with Hipchat too and we liked a lot but some developers choose grove.io due to it IRC interface.
- mumble - for audio meetings. We discovered that nobody likes “video” meetings. The tools are not so mature and requires a lot of internet bandwidth (very expensive in .br). Voice meetings are good enough for us. We are hosting our own mumble server on AWS. This is our favorite tools.
- scrumdo - our kanban and project management tools. There arre other (good) alternatives like Trello or sprintly.
But more important than tools is the team “mindset”. You need to work “remotely” even when you are all at the same room. Everybody using their own headsets (for mumble) and responding ASAP to the other comunication tools like grove.io.
-
-
Same here; I really like mumble and prefer it to G+, but we have some people who really like video. For a while G+ was so flaky that we’d start out with everyone on video and then slowly have people switch to audio-only as quality problems surfaced until it ended up back as an all-audio call. The reliability has improved recently, but it’s still a pain in the neck to navigate the UI compared to the simplicity of mumble.
-
I’m the only remote programmer in a team of 5, company of 20. I’ve been off-site for a year now, and we’re all happy.
One very important point: I moved away from the office location after several years on the team. Hiring your first remote employee is likely to be much harder than moving an existing employee to remote: you have to build up the working relationships at a distance.
Tools we’re happy with:
Hipchat for IM (it bounces to mail if recipient is unavailable, notification options are pretty good).
Google hangouts for morning standup (substitute skype/hipchat/your-favourite-alternative). A laptop is fine for this, but both camera and mic will be quite directional and limited-range: either get people to jump to right in front for their bit, or buy some slightly more expensive hardware for the office (a cheap mic that you hand around already makes a huge difference).
Google docs plus a voice (optionally video) channel for design discussions: the fact you can see each others' cursors in the doc means you can “point at things” which has been really handy.
tmux for working together on servers (stuff where in the office you’d have one person driving and one watching the same screen, but the watcher might want to take the wheel sometimes). This also works well with a separate voice channel open.
Stuff we’re missing (i.e., we feel like we want it, but not so urgently that we’re willing to pay for it):
Shared presence in code: screen-sharing is one-way, tmux is fiddly, there’s probably a good option out there but we don’t know it (yet). We get by with screen-sharing (and annotated pull requests for code review).
Shared sketches/diagrams, as you’d use a whiteboard for in person.
Habits and other “soft stuff”
Make eliminating communication friction a top priority. It is Not Ok if you’re prevented from getting something you need, because Tikitu’s internet in Greece is fried (or gchat on the standup machine won’t unmute, or the firewall on the VC server is rejecting connections from Eastern European IP blocks, or whatever). If left to grow, the smaller irritations of this kind will expand into a painful disconnect between your remote folks and home folks.
Timezones: a small timezone difference can be positive (a couple of hours of uninterrupted work before the office gets started); a big one is a pain. (I worked for six weeks with a 12-hour time difference, joining the morning standup at 10pm. I don’t recommend it.)
The remote folks are going to have to push a bit for remote-friendly behaviour from the home team. That might be easier if the home team also get a bit of “remote” (out-of-office) experience (a few days working from home, or similar): there will be things the home folks simply don’t notice are sticking points until they experience them themselves.
Regular trips home: I do every 2 to 3 months, ymmv. Keep a list of things that you’re putting off for in-person, and make sure it doesn’t get too long.
Your remote folks will miss out on the side discussions, that’s unavoidable (until there’s so many remote folks that the side discussions happen online…). But make sure to put the results of all side discussions somewhere they can see them. This can be a real culture shift; it’s paid off for us in other ways also (in particular, more documentation of intent and the reasoning behind decisions).
One last pro-tip: the remote folk should try to avoid this situation, if at all possible: https://twitter.com/tTikitu/status/428690448559779841
That’s a good protip, “Remote Workers should ensure all cabling is protected from livestock” – I’m going to write that one down.
We’re using TeamViewer and tmux for Pair Programming but we’ll start experimenting https://floobits.com/ for coding. https://talky.io/ uses WebRTC technology for screen sharing but, unfortunatelly, does not allow remote control.
What kind of problems have you had with tmux? We used it every day at my last job and found it to be rock-solid.
Not problems with the tool itself, but setup/workflow stuff: can I ssh to your box? (Oh, not since your last update. Ok.) Let’s look at it on staging. We need to rebuild the branch there? Ok. Now we’re good to go… wtf, someone’s customised the keybindings? Etc. Doesn’t help that half the team is using IntelliJ (PyCharm) and half vim.
For work on the servers (as opposed to pair-programming) it’s been a near-complete success; the only thing I’d like to see would be two side-by-side independent panes, so both can work simultaneously while keeping up with what’s happening.
Our biggest problem are the graphical IDEs/text editors that our team members use (PyCharm and SublimeText). But the https://floobits.com/ has plugins for both (and for vim, etc).
Gotcha; we had similar awkwardness around where to connect to–when I’m at home I can just set up port forwarding, but when I’m at a coffee shop or tethering from a park, that’s not gonna work.
One solution that worked fairly well with port forwarding was to have
.ssh/configfragments checked into a shared git repo so you could document the pairing username, port, and hostname you used. People pull that in and then can just runssh yournameand be off to the races. I really wish OpenSSH would add support for a~/.ssh/config.ddir though: https://bugzilla.mindrot.org/show_bug.cgi?id=1613Other things that have worked well: http://tmate.io and doing development on EC2 nodes.
Seems like it might be a good idea to use a VPN or ssh port forwarding to a VPS so that everyone uses the same stable rendezvous point?