How to Maintain the Productivity While Working from Home

The tool belt of the remote worker

Starting a new remote or home office, whether it's a contract project or a full-time job, can be a little intimidating if you're used to going to an office every day.

But this type of employment is becoming increasingly popular and is advocated by some very reputable companies.

We have been working successfully with these tools for Remote Work for years on projects of varying size and duration. We have listed some of the best practises for remote working based on our experience. The guide for working remotely and from home ranges from specific recommendations for software and hardware to tips on how to meet your team's deadlines.

The setup of the remote or home office

The right office equipment is really important. It will both make you more productive and make you look more professional. For example, a headset is essential to avoid echoes during online conversations; little things like that are very important when working remotely.

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

• Headset - Wired headsets are convenient because the battery doesn't run down in critical times. You can use iMicro headsets. As a headset it has two great features: Since it is powered via USB, I don't have to worry about keeping the batteries charged and it is very cheap to replace if it breaks in my bag. This headset is a bit uncomfortable for long conference calls; if you make a lot of them, I recommend the Corsair Vengeance 2000: a comfortable, wireless headset with a battery that lets you work all day. (By the way: none of these are referral links)
• A quiet place to think, with a door that closes - 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 I have a tethering facility on my phone in case the DSL line goes down. If you constantly have Skype problems or drop calls, you will become both less reliable and less professional in the eyes of others who may be trying to manage several remote employees
• Skype - It's great for adhoc conference calls, instant messaging with customers, or even setting up low-ceremony chat rooms
• SkypeOut - Which allows you to receive and make calls to Skype contacts from your phone.This is fantastic, especially for times when you're not sitting at your computer and (you've made a mistake, the customer has an emergency, etc.)
• Electric kettle - Sometimes you want hot coffee, but you don't want to disturb the flow to get some.
• Gallon Jug of water - For the electric kettle or for drinking. For long coding sessions or long telephone conferences

Some of these sound obvious, but you would be surprised at the number of remotes that don't meet all the requirements here. As developers, we need a quiet, undisturbed space to think. And as remote workers, we need a quiet place where we can have undisturbed conference calls, meetings, pair programming sessions, etc. Just working on the couch is probably not a good long-term solution for remote working.

Find Out More... 27 Best Free Tools for Online Collaboration in 2020

Software Tools to Support Remote Working

There are a number of good software tools that complement your typical development environment and help you overcome the challenges associated with working remotely. Here are a few of the software tools to get the maximum productivity of remote employees:

• AwayFind - which is great for urgent emails, especially last-minute messages from a session participant, as it forwards their messages to you via SMS
• Time Zone Converter - for working with customers and colleagues around the world. I like Time And Date's World Time Clock, Every Time Zone, World Time Buddy, or The Time Now for a version that is more accessible to the visually impaired
• Chat/IRC rooms - for everyone on the team. This can be a formal room (such as a campfire room) or simply a Skype chat room (in the style of Keep It Simple, Silly)
• Bugtracker - this deserves its own section, see below

Always confirm both time zones when planning sessions. And when you receive an invitation, always count backwards and make sure you get the same numbers. If the meeting covers several time zones, I like to include UTC time. Since everyone should know their deviation from UTC time, this is another check to make sure everyone is on the same page.

You May Also Want to Read: Advantages of Letting Your Employees Work Remotely

Best Practices for Remote Work

Bug Tracking

There are three things you want to know from a bug tracker you use:

• What are you currently working on?
• What do you have on your plate for the next release?
• What are the results of the entire team for this version of the software?
  

Each of them has a purpose.

First, "What are you currently working on? If you're working in a traditional office, you'll have background interviews - this gives you a general idea of what everyone else is doing. An explicit marker in the bug tracker system that says, "Yes, I'm actively working on it right now," can introduce a similar pattern and feeling into remote working.

Second, "What do you have on your plate for the next release" means "What bugs are you responsible for" or "What bugs are you working on". Certainly there is a back and forth in every team, but it's also good to know who to ask when you want to catch a bug or need help finishing your bugs for the next version.

It is also possible that your team does not work this way at all: For example, your workflow might be to assign only one bug to each developer to start with, and to pick up the unassigned stack when the one bug is fixed. This can also be productive.

The "next version of the software" doesn't have to be something big. It's good for everyone to know what's coming in this new version. Especially if you pick up unassigned tickets when your current ticket is complete.

Team Communication

For some, team communication is the most intimidating part of working from a distance or from home. But this will only be a problem if you allow it.

In an office, when you walk past everyone on the way to your desk, there's a bit of banter when people say "hello". Your employees know you're at work because they see you over there, at your desk, at work.

Remote workers need to be a bit more explicit - no one knows you're working unless you tell them. But if you put the right communication practices in place, your colleagues will be available at the touch of a button instead of strolling around the office, going down the elevator, etc.

These tips are more applicable to a remote employee as part of a larger team, but can be useful when it's just you as the sole developer.

Read More... 6 Effective Communication Methods for Managing a remote team

Make your presence felt: Do not become invisible
I picked up some of these ideas from the Wide Teams Podcast Episode 48.

At the beginning of the day, go 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 going to IRC and asking about kids, weekends, sports teams, or weekend hacks. If people know that you are working hard at home, you will not become invisible. Build a relationship and let people know that you are there.

Chat with other people and make sure you stay in touch with your colleagues. This is different from meeting people in the coffee room, etc., etc. You have to explicitly reach out and stay in touch so that people are ready when you hand over code or need help.

Remote freelance performances are always different. (That's part of the appeal!) Sometimes you are brought into an existing development team purely as an addition to the staff. Perhaps this team has been together for some time, and in this case they have already established communication practices.

On the other hand, sometimes you are the only developer on the project working with a non-technical customer. You can set up your own best practices for software development and have some control over how the operation is run. Below are some best practices from my approximately ten years of remote work experience. Most of them are based on half-weekly (20 hours/week) or full-weekly (40 hours/week) schedules.

Stand-up sessions
There is a strong case for holding stand-up meetings to discuss the status of the project. These are very common in traditional offices, but there is no reason why they cannot be productive for the remote team: They are just another way to force communication between the two parties - customer and developer.

A traditional stand-up meeting asks what you worked on yesterday, what you will work on today, and whether there are any obstacles in your path. This format may or may not work given the size of your team: if it's a single developer project, these questions don't make sense.

How often you should hold a stand-up meeting really depends on the size and culture of your team. But here are some recommendations:

• 1-3 developers: 2 stand-up meetings per week
• 4+ developers: daily stand-up sessions
• For 1-3 developers, these questions are usually taken for granted: they know what each developer is doing because it's easy to track their individual work while they're plowing through issues: Everyone knows what everyone is doing because there are simply not that many people working.

With larger remote teams, there are more parts in motion: they want to make sure no one steps on someone's virtual toes by replicating work or making incompatible changes.

Advanced remote teams may have other methods of keeping everyone on the same page without calling an actual session while working from home. I still like to make phone/skype/hangouts with someone and have a meeting that way.

For small teams, two stand-up sessions per week work really well: course corrections are made quickly, but the developers still have something substantial to report at each session.

Delivering the next version remotely

Depending on the size of the project, I like the results to be sent to the customer weekly for small projects (1-2 developers) and biweekly for larger projects (3+ developers). This rhythm gives the developers enough time to complete large parts of the work, including an interface (or improved user experience) that the customer can see.

For non-technical customers, the only metric they can use to measure progress is what they can see on the screen.

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

Depending on the type of software project, not all of these client releases are released to the public. For example, if you are working on a Rails project, you may want to deploy approved changes immediately; on the other hand, if you are working on a mobile application, you may want to call a release "1.3a10", but the current release is only part of the larger feature set of a new version 1.3 of the software that will be released later.

This is where the best practices of the remote bug tracker come into play. With bug tracking, the customer knows what's going on:

• What is on the team's plate for this deliverable
• When it is completed
• When the work has been approved by the client

The customer knows what to expect from this release and the developers know what work lies ahead.

Conclusion

Starting to work remotely or from home can be quite a change, both for you and for the customer. I have done it very right and very wrong. But if it goes right, it can be an excellent way for customers or employers to solve the "talent crunch" problem and provide a wider range of opportunities for developers who live outside the major technology centers or "startup" centers. There is a whole world of efficiency when developers work remotely with the right local best practices.