How to Maintain the Productivity While Working from Home
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 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:
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
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:
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
There are three things you want to know from a bug tracker you use:
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.
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.
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.
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:
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.
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:
The customer knows what to expect from this release and the developers know what work lies ahead.
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.