1. 8

I’m looking for success stories of teams moving from an “everyone under one roof” model to some people working remotely some (or most) of the time. If you have successfully made this transition, what tools or techniques helped you?

We use IRC currently for team chats. It works well when everyone is online, but it’s annoying that people won’t see messages aimed at them while they’re disconnected. (IRC bouncers are probably a no go, and email isn’t a good substitute for informal chat.) I have heard good things about Google hangouts, but I worry G+ is too infectious for that to be practical.

We practice Kanban & a daily standup. I suspect that booking a meeting room with AV equipment for standup every day won’t be practical, so any advice for conducting virtual stand ups would also be very appreciated.


  2. 10

    I’m a remote worker for a company moving to a more agile style from a very rigid one. My background is in what might be called ‘highly agile’ environments, or at least environments where the concept of Agile practices were well understood and generally accepted. I’m also the only home-office remote worker (as opposed to a remote office, we have one such office located in France). I have some general advice I’ve learned from working remote here, having transitioned from a non-remote job at another company.

    The first thing you need as a remote worker is to be omnipresent. This sometimes means being available-to-work a little before and after normal hours, it does not mean you need to be actively working during that time. My policy is that I work 9-5, taking ~1 hour for lunch at my desk, but I’m available to answer questions/pair on problems from ~8:30 to ~7 or so, after that I’m 100% disconnected. This availability helps to remind people you exist, the hardest problem to solve as a remote is that people will – inevitably – forget you exist. By being always around, you lower the barrier to communication with you to the point of being nonexistent, I’ve found this helps a lot in making sure people remember you exist, and therefore making sure that they remember why you’re there.

    Similarly, there is no issue to small to have a call about, I use skype extensively, and unless I can easily ask or answer a question in a sentence or two, I will be calling you. Hangouts are fine, but I find that skype is less distracting for me and our team. We also use skype chatrooms, though I would prefer something like IRC or hipchat. Skype is nice in that messages sent while offline will pop up when you sign back in with a pleasant ‘blorp’, I think hipchat does this too. For IRC, a bot can note that someone was mentioned in chat who wasn’t present and notify them of a message when they return – I know lambdabot does this, I suspect some of the other popular IRC bots do as well.

    The most important moral of all this is communication – you are gaining flexibility at the cost of ease of communication. Working remote (esp. from a home office) is wonderful – the commute is great, the coffee is always good, and you have total control over your work environment. However, it is vitally important to ensure you are doubly responsible when it comes to communication, especially if you’re the lone remote worker. You are - a priori - assumed to be sitting in your pajama’s and doing nothing, you have to prove you are not, being in a state of ‘always available for contact’ is a great way to reinforce that you are working as hard or harder than your non-remote colleagues.

    For standups, I usually just have someone skype me from their laptop, phones also work too – you don’t necessarily need video (though I like to use it as much as possible – a good webcam is a must, a 1080p webcam runs like 50$, putting a face to the formerly disembodied voice helps with the whole ‘don’t forget me’ thing). I also make sure I have a weekly check-in w/ the ‘big boss’ (the cross-team lead who hired me, as opposed to my ‘work boss’, the guy who actually gives me my instructions) for about 10-15 minutes to make sure they know what I’m up to, and also to help address any concerns I have, they have, or someone has. I also end up doing a lot of broad-stroke technical advising, but that’s more to do with why I was hired for this particular job than my remote-y-ness.

    I make a habit of going down to the main office semi-regularly (on company dime), probably once every six months or so. This helps, again, with the “I actually work here” problem, and also allows me some time to directly interact with folks and make managers happy, etc.

    Ultimately, unless your company is predisposed to remotes, the first guy will always have a tough hill to climb to prove that it works. I think it works great, I’m definitely more productive and I feel less stress when working. I don’t mind taking breaks as needed and breaking up my day because I know I can always make up the time without having to worry about getting home at a reasonable hour. The flexibility is great and it shows in my work, I can say without doubt that I write better code (and build better devops infrastructure) now than I ever did when I worked on site all the time.

    1. 6

      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).

      1. 2

        One last pro-tip: the remote folk should try to avoid this situation, if at all possible: https://twitter.com/tTikitu/status/428690448559779841

        1. 2

          That’s a good protip, “Remote Workers should ensure all cabling is protected from livestock” – I’m going to write that one down.

        2. 2

          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.

          1. 2

            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.

            1. 2

              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.

              1. 1

                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).

                1. 1

                  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/config fragments 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 run ssh yourname and be off to the races. I really wish OpenSSH would add support for a ~/.ssh/config.d dir though: https://bugzilla.mindrot.org/show_bug.cgi?id=1613

                  Other things that have worked well: http://tmate.io and doing development on EC2 nodes.

                  1. 1

                    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?

            2. 6

              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.

              1. 1

                I’ve tried to get mumble used at my company (as opposed to skype) to make communication more fluid (can just jump into a channel and start talking, rather than calling), but we hit a local optima with skype. Neat to hear that someone is actually using it for real.

                1. 1

                  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.

              2. 3

                I’m interested in this topic. We use a hipchat room entitled ‘Standup …’. All team members post a quick message to this room, with their updates. This keeps a record/history of the stand-ups from each member, and the remote employees updates thread equally with the others. We only have 2 remote workers, with 14 others co-located. These remote workers join hangouts, and the webcams are utilized. But they are really missing out on the side conversations. We work with about 20 individuals in a single open room, with whiteboards, and no walls. Quite frequently, there are multiple developers around one screen. And many conversations occur in the kitchen, basement, ping-pong / pool tables, etc… The remote employees really miss out on this unfortunately. We haven’t tested this in our group, but other teams in our organization have tried a dedicated google hangout, with the remote employee dialed in with a webcam. There is a TV/mic/webcam setup in the developer room, so the remote employee is able to be virtually present. This seems to work, so we will try this. The only other thing we are testing is giving the remote employees tasks that are more isolated / research oriented. Since these tasks require less direct interaction / impromptu meetings, the remote employees are able to focus and deliver better results. I am however very interested to hear what other tactics are successful. I’ll second jfredett about weekly 1-on-1’s with the manager, frequent visits to main offices, and high quality webcams. One last bit, I feel it is very difficult to maintain or develop the same culture remotely. The atmosphere of the workplace is hard to replicate for the remote workers. That’s my $0.02

                1. 3

                  You don’t need a meeting room with AV, but you do need something better than laptop microphones. A minimac or laptop with a Jabra microphone is good. You may find it helpful to put a minimac near the coffee machine or in the spot where you’d typically run your standups (at standup height, perhaps). If the remotes can call in and the box autoanswers, that may be good. If you can see the team, you can also see who’s not there, and that’s a great deal better than bothering people in IRC with questions like “can you look and see if Kim is in the office?”

                  Make sure to start on time. Same time each day, not a minute before or after. Starting ten minutes late is OK when you can see the team anyway, but the remotes will sit on their thumbs waiting and you as team lead won’t notice that you’re irritating part of the team. Having the standup box autoanswer when a remote calls in helps with that.

                  Watch out for people who mumble too far from the microphone. It’s not necessary to hold the microphone, but mumbling five meters away won’t do.

                  Be prepared to tweak.

                  Jabber chat rooms save messages in the manner you want, but client support is scarce. YMMV.

                  1. 3

                    It really depends on whether you’re adding someone new who’s remote to a team that has so far been co-located (basically doomed) or having experienced team members move away from the office (possible to do well). IMO the only way to do mixed local/remote teams is by having existing team members spin out of the mothership who know their way around the project and have good connections with the rest of the team.

                    The problem here is that once you want to bring on someone new, they basically have to go through the same thing of starting out locally and possibly going remote in the future, unless you can manage a full transition from mixed remote/local to fully-distributed at which point you can bring in fresh remotes. It seems really difficult to do this gradually. Apart from the suckage of “why does he get to work remotely and I don’t” tension, this nullifies one of the biggest advantages of a remote team from the company’s perspective: the vast expansion of the talent pool.

                    Personally I don’t see anything wrong with IRC for team chats as long as you have a way to contact someone in cases where it’s urgent. If I’m away from my machine having dinner and someone pings me in chat thinking I’m still working, I certainly don’t want my dinner interrupted. But if there’s an emergency, obviously I need to be reachable by SMS.

                    My primary piece of advice would be to reduce the friction of setting up a pairing session as much as possible so people feel comfortable asking for another pair of eyes on what they’re doing rather than getting stuck and wasting hours on a problem that someone else could help untangle in minutes. I’ve had luck using http://tmate.io and https://syme.herokuapp.com for that.