The Remote Worker’s Tool Belt

The Remote Worker’s Tool Belt

Starting a new remote or work from home gig, be it a contract project or a full-time job, can be a little intimidating if you’re used to going into an office day after day.

But this style of employment is growing in popularity, with some very notable companies lending it their endorsements.

I’ve successfully worked remotely using these tools for years now on projects of various scales and durations. With this post, I hope to enumerate some of the best practices that I’ve picked up for working in a variety of situations. The remote and work-from-home guide here ranges from specific recommendations for software and hardware to tips for hitting your team’s deadlines.

The Remote or Home Office Setup

I can’t stress enough the importance of having the right office setup. It will both make you more productive and appear more professional. For example, a headset is crucial for avoiding echo during online calls; little things like this go a long way when working as a remote.

Here are some tools for working remotely that I consider essential in my own home office:

• Headset. I really like wired headsets in particular because they don’t run out of battery at critical times. You’ll be wearing it a lot, so make sure you get something comfortable. I have two iMicro headsets: one for my desk and one that I pack in my laptop bag. As a laptop bag headset, it has two great qualities: because it’s USB powered, I don’t have to worry about keeping the batteries charged, and it’s very cheap to replace if it gets broken in my bag. Actually, I find this particular headset a little uncomfortable for long conference calls; if you’re doing a lot of those, then I recommend the Corsair Vengeance 2000: a comfortable, wireless headset with battery capability, allowing you to work all day. (By the way: none of these are referral links.)
• Quiet place to think, with a door that shuts–especially if you live with other people, and especially if you have a family.
• Stable Internet connection, or good backup connection. For example, I have DSL and have setup tethering on my phone if the DSL goes out. If you’re constantly having Skype issues or dropping calls, you’re becoming both less reliable and less professional in the eyes of others who might be trying to manage several remote employees.
• Skype. This is good for ad-hoc conference calls, instant messaging with clients, or even creating low ceremony chat rooms.
• SkypeOut, which lets you take and make calls from your phone to Skype contacts. This is awesome, especially for times when you’re away from your computer and (you’ve miscalculated a time, client has an emergency, etc.).
• Electric kettle. Sometimes I want hot coffee but, don’t want to disturb my flow to get some.
• Gallon jug of water. For the kettle, or for drinking. For long coding sessions, or long conference calls.

Some of these sound obvious, but you’d be surprised at the number of remotes who don’t hit all the marks here. As developers, we need a quiet space to think, uninterrupted. And as remote workers, we need a quiet place to host conference calls, meetings, pair programming sessions, etc., uninterrupted. Just working on your couch is probably not a good long-term remote work solution.

Software Tools

There are a bunch of good software tools out there to supplement your typical development environment and help you overcome the challenges associated with remote work. Here are a few that I really like:

• AwayFind, which is good for urgent emails, particularly last minute messages from an attendee of a meeting, as it forwards their messages to you via SMS.
• Time Zone Converter, for working with clients and colleagues around the world. I like Time And Date’s World Time Clock, Every Time Zone, and World Time Buddy.
• Chat/IRC rooms for everyone on the team. This could be formal (e.g., a Campfire room) or just a Skype chat room (in Keep It Simple, Silly) style.
• Bug tracker–this deserves its own section, so see below.

When planning meetings, always confirm both time zones. And when you get an invitation, you should always do the math backward and make sure you come up with the same numbers. If the meeting involves multiple time zones, I like including the UTC time also. Since everyone should know their offset from UTC, this is yet another check to make sure everyone’s on the same page.

I was on a decently-sized Rails team a few years ago. Several team members worked remotely for at least part of the time, and the team culture was that much work would be done in the evenings. I proposed setting up a chat room through the official team leader at the time, pointing to Campfire or some other paid chat service. Several weeks went by with no action and I decided to setup a Skype chatroom with just the developers, to test my theory that a chat room would be an asset for the team. This experiment proved very successful – so successful that we just kept using Skype chat instead of another solution. This Skype chat room was still in use when I left the project almost a year later. Sometimes, simple can be the best option.

Later on, during a critical deadline for the same project, we set up a Skype chatroom that included the developers, business analysists, the project managers and the client, so questions could be addressed quickly by the general group. While not as active as the developer-only chat room, it still worked really well. Skype chats can be moderated and controlled by some group chat commands, setting chat roles and setting access permissions, which allows you to really customize the chatroom to your use-case. Even a setup of such simplicity can improve remote productivity.

Remote Work Best Practices: Bug Tracking

I like to know three things from a bug tracker I’m using:

• What am I working on right now?
• What’s on my plate for the next release of this software?
• What are the entire team’s deliverables for this release of the software?

Each of these has a purpose.

First, “What am I working on right now?”: When you work in a traditional office, you have background chatter–this gives you have a general idea of what everyone else is doing. An explicit marker in the bug tracker system stating, “Yes, I’m actively working on this right now”, can introduce a similar pattern and feel to remote work.

Secondly, “What’s on my plate for the next release?” means, “What bugs I’m responsible for” or “What bugs I’m handling”. There’s certainly some back-and-forth in every team, but it’s also good to know who to ask if you want to grab a bug, or need some help with finalizing your bugs for the release.

It’s also possible your team doesn’t work like this at all: for example, your workflow might be where each developer is only assigned one bug to start with and picks off the unassigned pile when their one bug is done. This can be productive as well.

The “Next release of the software” doesn’t have to be anything big–I’ve been on teams where the “next release” meant, “3 days from now, we’re going to release a new alpha build for the client”. But it’s still good for everyone to know what’s coming up in this new release. Especially if you pick off unassigned tickets when your current ticket is complete.

I’ve included some recommendations for specific bug trackers at the bottom of the post.

Remote Work Best Practices: Team Communication

For some, team communication is the most intimidating part of working remotely or from home. But this will only be an issue if you let it be.

In an office, as you stroll by everyone on the way to your seat, there’s a bit of banter, people saying “Hello”. Your coworkers know you’re at work because they see you, over there, at your desk, working.

Remote workers need to be slightly more explicit–nobody knows that you’re working unless you tell them. But if you establish the right communication practices, your colleagues will be available at the press of a button, rather than a stroll across the office, down the elevator, etc.

These tips apply more for a remotely managed employee as part of a bigger team, but may be useful if it’s just you as the sole developer.

Making Your Presence Felt: Don’t Go Invisible

I picked up several of these ideas from the Wide Teams Podcast Episode 48.

At the beginning of the day, get on IRC (or whatever tool your team uses) and say “Hello”, chat about how people’s days are going, etc., etc. Even if it means getting on IRC and asking about kids, weekends, sports teams, or weekend hacking. When people know you’re currently hard at work at home, you don’t become invisible. Build a relationship and let people know that you are there.

Chat with people on chat and make sure you stay involved with your colleagues. This is different than when you bump into people in the coffee room, etc., etc. You need to explicitly reach out and stay in touch so that when you commit code or need assistance, people are ready.

‘Starting day’, ‘Lunchtime’, and ‘Be back’ Messages

Along with making your presence felt, you should also let your remote teammates know when you’re not working. Just like in a traditional office setting, you don’t want to disappear for the rest of the day and leave your colleagues hanging.

If you’re on a team with a number of other developers or managing remote employees, it makes sense to check in when you start your work day. A simple “Good morning, everyone” to let people know that you’re at your desk ready to start work on the project, and no longer at home or in bed.

Sending “Be back in 1 hour” messages for lunch or work breaks during the day is nice too. Remote work is great for many things, but one worrisome scenario is that you ask your colleague a question and receive no response. Are they not responding because they’re away for 30 minutes? Or because they are deep in the zone and not listening to chat? Maybe in a meeting? “Be back in…” messages can alleviate these concerns and smooth out the workflow.

When you’re done for the afternoon, let people know when you’ll be back. Maybe it’s “See you all in the morning”, or “Be back later this evening to get [x] done”. But like the “Back in 1 hour” messages, they set a certain expectation to which your team can adapt.

There’s an interesting startup called Sqwiggle that may solve some of these problems (although I haven’t tried it myself yet). In addition to taking a picture of you every few seconds, it also lets team members click on your picture to start video/audio chatting, as well as providing a text chat component. The idea behind the picture is to see, at a glance, if you’re at your computer or not. (There’s nothing worse than trying to chat with someone online and not hearing back quickly. Are they caught up with something else? Deep in the zone? Don’t see the chat notification? In the bathroom right now?). I heard about Sqwiggle on the Wide Teams Podcast Episode 83.

On Projects Where You Can Setup the Best Practices

Remote freelancing gigs are always different. (That’s part of the appeal!) Sometimes you’re brought into an existing team of developers purely as staff augmentation. Maybe this team has been together for some time and, in that case, they’ve already established communication practices.

On the other hand, sometimes you’re the only developer on the project, working with a non-technical client. You can setup your own software development best practices and have some control over how to run the operation. Below are some best practices from my decade or so of remote work experience. Mostly, these are targeted at half-week (20 hours/week) or full-week schedules (40 hours/week).

Standup Meetings

There’s something to be said about holding standup meetings to talk about the state of the project. These are very common in traditional offices, but there’s no reason why they can’t be productive for the remote team: they’re just another way to enforce communication between the two parties: client and developer.

A traditional stand-up meeting asks what you were working on yesterday, what you’ll be working on today, and if there are any obstacles in your way. This format may or may not work given the size of your team: if it’s a single developer project, then these actual questions make no sense.

How often you should have a standup meeting is really dependent on team size and culture. However, here are my recommendations:

• 1-3 developers: 2 standup style meetings a week
• 4+ developers: daily standup meetings

With 1-3 developers, these questions are mostly self-evident: you know what each developer is doing because it’s easy to track their individual work as they plow through tickets: everyone knows what everyone is doing, because there’s just not that many people doing work.

With larger remote teams, there are more parts in motion: you want to make sure that nobody is stepping on anyone’s virtual toes by replicating work, or making incompatible changes.

Given Toptal’s per-week payment structure, two meetings a week gives the client enough time to express concerns about the project before they feel cheated out of a weekly rate. Just having one meeting a week could mean that the client is unhappy about the quality of work, and the developer has no time to adjust the deliverables.

Advanced remote teams may have other methods of keeping all the stakeholders on the same page without scheduling an actual meeting while they work from home. I still like getting on the phone/Skype/Hangouts with someone and having a meeting that way.

For small teams, two standup meetings a week works really well: course corrections are made quickly, but developers still have something substantial to report during each meeting.

Delivering on the Next Release Remotely

Depending on the size of the project, I like deliverables sent to the client weekly for small (1-2 developer), and bi-weekly for larger (3+ developer) projects. This rhythm gives developers enough time to complete sizable chunks of work, including an interface (or improved user experience) for the client to see.

For non-technical clients, the only metric by which they can guage progress is what they can see on the screen.

It’s important for developers to remember, especially with non-technical clients, that progress you can visualize with a user interface is often the only thing that matters to the client. Non-technical clients don’t care that you pushed out 500 lines of code this week, or that you had a hard time interacting with some web service; the only metric by which they can gauge progress is what they can see on the screen. That’s not to say that doing good work on the back-end is irrelevant, but rather that you need to make all this good work tangible in the eyes of the client.

 

Which is why I like weekly or bi-weekly deliverables. Anything shorter than that often puts the developer in a hard place: maybe they get stuck doing back-end work for two days and don’t have time to finish the interface, so they have nothing to show the client.

Depending on the type of software project, not all of these client releases will be released to the public. For example, if you’re working on a Rails project, you may want to deploy approved changes immediately; on the other hand, with a mobile app, you may call a release “1.3a10”, but the current release is just part of the bigger feature set of a new 1.3 version of the software that will be deployed later.

This is where the remote bug tracker best practices come into play. With bug tracking, the client knows:

1. What’s on the team’s plate for this deliverable
2. If it’s been completed
3. If the work has been approved by the client.

The client knows what to expect from this release, and developers know what work is ahead of them.

If your remote team is mature enough to use continuous deployment and/or Kanban then that’s fine. However, these are both very advanced techniques that are more suited towards organizations with a strong, developer-based culture. Most organizations, where custom software development is seen as necessary but costly, are probably not ready for either of these techniques. Why’s that? Two things I’ve seen is that the client can’t keep up with the number of changes developers want them to review, or priorities change too rapidly for development to get any one thing done.

Recommendations

If you do happen to walk into a team where you’ll be establishing the best practices, I’ve listed some tools below for managing your remote work. Keep in mind that these are just my recommendations: certainly, this guide isn’t for everyone; and if you don’t like these tools, there is probably a tool that fits your needs better.

• Planscope.io, in weekly mode. This is a time tracker + bug tracker + project estimation tool that sends clients daily emails when you work on their project and lets them see how things are going in terms of progress and budget. This is great for projects of 1-4 developer/months in size.
• App Trajectory is a bug tracker for small teams with a focus on estimating and breaking the project down into one-to two-week chunks (iterations). App Trajectory can tell you how much work you’re completing in an iteration, and how many iterations until all the known work is complete. This is great for projects 2-12 developer/months in size.
• Pivotal Tracker is a bug tracker tool for clients with a focus on Agile methodologies. This is great if you are doing formal Agile iterations or have a project size measured in developer/years.
• FlowDock for chat. Flowdock offers some advantages over plain IRC or Skype chat: in addition to integrating with popular services, it also lets you tag conversations for quick reference later. FlowDock also keeps a list of status activities (code checkins, etc.) which are separated from general chats. (I.e., in the web interface, automated status updates are on the left, while chats are on the right.)
• Again, Campfire is also great for chat.

Conclusion

Getting started with remote or work from home can be quite an adjustment, both for you and the client. I’ve had it go very right, and very wrong. But, when it goes right, it can be an excellent way for clients or employers to solve the “talent crunch” problem, and create a wider range of opportunities for developers who live outside major technological centers or “startup” hubs. There’s a whole world of efficiency to be gained from developers working together remotely with the right best practices in-place.

This was original written by Ryan Wilcox on TopTal’s blog

Read More at The Remote Worker’s Tool Belt

from Web Design Ledger http://webdesignledger.com/remote-working-tools/