What happens when your client is out of state and the rest the development team is in a different zip code and you have software to deliver? You work remotely, of course.
Usually Keyhole blog entries address specific technologies, but this past year I have worked remotely on more than one occasion so I’d like to share my experiences. Distributed development teams are not unusual in this day and age, and working remotely can be rewarding and challenging. Luckily there are many ways to effectively contribute your skills and experience to a successful project.
In this post, I will examine what it takes to effectively contribute to a team when working off-site, with a particular focus on some tools and strategies that can help.
Remote Tools
I have used various technologies when working off-site. A fast internet connection and modern computer is a given with modern development teams, so I’ll examine the other tools I’ve used. I’ll break down the tools into communication, collaboration, and development categories.
Communication
Communication tools are important for obvious reasons. How else will you get and convey information to your client?
A lot of organizations I have worked with set up virtual private networks (VPN). When working with these organizations, I’ve installed a VPN mobile client such as Cisco’s AnyConnect. Once you have client-provided credentials, you can remotely login to client’s VPN and have access to all the shared resources on their network.
This will usually provide you access to all the necessary tools for communication, document sharing, planning, source repositories and development tools. VPN connections are secure so that is one less thing to worry about.
Other communication tools include:
- Email – Microsoft Outlook, Google Gmail
- Chat – Cisco Jabber, Google Chat, Slack
- Conference/Video Conference – Cisco WebEx, Microsoft Skype, Join.me
Communication tools enable me to interact with my team easily and quickly. Similar to communication tools are collaboration tools in that they provide an easy way to share information.
Collaboration
Collaboration tools make it possible to easily share information, such as documents, files, and videos. Generally these tools enable users to store their information in a central location (Cloud-based) that can be accessed with an internet connection.
Google Docs and Microsoft 365 are two cloud-based services that I have used in the past. It is very convenient to upload a document to one of these services and know that my team has access to it.
Communication and collaboration is important, but I’m a software developer, so I need tools to help the development process.
Development
Development tools are a broad category. I will focus on those tools that help me work remotely. Modern development teams use code repositories to store their code base. Luckily I’ve been able to access two of the most popular repository tools remotely: Git and SVN.
Both are commonly used by development teams and both have functionality built in that enable remote access. It is necessary to have the repository admins to give you access, but otherwise, working with these tools remotely is quite easy. Many standard development environments such as Eclipse and Microsoft Visual Studio have built in access to common repository tools such as Git and SVN, so working remotely with these tools is quite painless. Once you have you tools set up, working remotely can be very straight forward.
Challenges & Suggestions
There is more to working remotely than just having the tools set up. The biggest challenge for me has been communication. In my opinion, talking with someone in person is the best way to communicate. This isn’t an option most of the time when working remotely, so what do you do? To start, you take advantage of all the tools at your disposal.
Use these tools to ask questions, provide updates and any other pertinent information. Since this form of communication isn’t as effective as face-to-face contact, you may have to be more careful with the information you’re trying to convey.
Sometimes you receive an email, or review a requirement and aren’t clear on certain aspects of the communication. If you have questions, ask questions. Don’t be afraid to ask as many questions as necessary to understand what is expected to be accomplished. Development work is very detail-oriented, so getting clarification is crucial.
In addition to questions, don’t be afraid to provide status updates. Let the rest of the team know what you’re doing. Status updates help alleviate the out-of-sight, out-of-mind situation.
Frequent communication will help alleviate the out-of-sight, out-of-mind scenario, but if possible, try to arrange some person-to-person time. Make a trip to the team’s office if you can. Face-to-face interaction helps build connections and can be very enjoyable. Meeting team members in person helps put a face to the name and creates a connection. People are social, so personal interaction helps your relationship with your team.
Working remotely isn’t all bad. There is a certain amount of flexibility when not in the office. You avoid having to commute to the office, usually don’t have as many meetings, and have a certain level of autonomy. First and foremost though, you must get your work done. If you can overcome the communication issues and take advantage of the extra flexibility of being remote, you will be a valuable member of the team.
Final Thoughts
My personal preference would be to on-site with the rest of my team. I enjoy the personal interaction with my team members that you don’t get working remotely. As a consultant I don’t always have that option, so I adjust to working off-site.
With the right tools and attitude, working remotely overall has been enjoyable. I’ve been able to contribute to my development teams and get a sense of satisfaction of a job well done. What tools and strategies have you used?
| Reference: | The Remote Development Experience from our JCG partner Ron Moddesette at the Keyhole Software blog. |
As a freelancer I’ve had experience in full-onsite, full-remote and mixed environment. I think the best one is the mixed one: it means that you go onsite whenever it’s the best use of your time, not because it’s like that every single day. The right balance should be around 40-50% onsite and the rest wherever. In full-remote I had the experience that not being physically there gives less “weight” to your question and alerts (compared to going to the person you need to communicate to); it also doesn’t help you to really feel part of the project (which is always… Read more »