Remote software development team best practices
Remote work is very popular nowadays. In an ideal world, every CTO would have unlimited access to talented people living nearby the office and having the expectations their employer may fulfill.
Different reports present different numbers, but in general, the demand for software developers is still much higher than the supply for a long time. So, remote work is sometimes the only option to increase a company's capability of doing their main business.
But how to be a good partner to a company when you see each other only a few times a year?
Be active
To do remote work effectively, you have to be really proactive. If you aren't active on Slack, you become invisible to the client. Answering emails after 3 days is not an option. Probably you're doing your job, but to give your client the feeling that you are part of the company, you just can't ignore public discussions, not answer open questions, etc.
What I've observed is that the number of people actively involved in meetings is not linearly dependent on the number of participants. In 3-people meetings, it's highly probable that everyone will have something to say. But when 13 people participate, I would be surprised if more then 4-5 people were involved. Can you afford to be in this quiet group?
People working on-site see each other for a few hours a day; they have many chances to talk. But for remote workers, it's sometimes the only chance to talk to some people with whom they work on a daily basis. It's good to seize the opportunity. But to do it well, you have to be prepared, ask the right questions, and offer solutions.
Be transparent
One of the most important things when working remotely is trust. I think that being transparent is the most important factor that may help in building relationships based on trust. I identified two main areas where being transparent is critical for remote teams:
- Working time
- Delivery
Be transparent - working time
Before I started to work as a member of a remote team, I was working in an IT department of a bigger company. We would sit together for 8 hours a day. Even if someone had to be off for a few hours, everyone knew about it. The popularity of flexible working time is something really great in our profession, but when working remotely, you have to remember that your client does not sit next to you, and it's always good to inform them upfront about longer off times.
Be transparent - delivery
Estimates come with some inaccuracy by definition. It may sometimes happen that you fail to deliver some feature or fix a bug on time. When working on-site, everyone sees you trying to deliver an underestimated story. It's not so visible when you work so hard off-site.
Use existing processes (for instance, daily standup) to talk about problems as soon as you identify them. Inaccurate estimations are acceptable if they have real reasons. But informing about delays is almost always required, and not being transparent here may undermine the relationship you have with your partner.
Don't be just a resource
A casual developer's day consists mostly of coding and meetings. The number of meetings often depends on the seniority, but if you work in a Scrum team, you have about 4 mandatory meetings in a Sprint plus daily standups. Not too much. So you can be focused on tickets, and probably that's why you were hired as an external team member.
But can you do something more for the client? Are there any problems with the existing process you see, and you have an idea of how to improve it? Or maybe there is no space to share the technical news or interesting presentations with other developers, and you think it would positively influence the company's technical culture? There are many options to not only be a coder, which in remote teams is very important.
Have your tools prepared
It's strange, but IT companies building cutting-edge solutions sometimes have problems with basic technical things like the internet connection or setting up meetings with screen sharing and audible voice. It's very similar to developers having problems with the microphone or headphones.
You probably meet developers experiencing such problems often, and those that have it rarely or never. I bet both groups have the same types of problems, but one simply identified the root cause and solved it right after it occurred for the first time.
You may have some issues once, maybe twice, but if you have some problems constantly, it means that you are not paying enough attention to them. If you work remotely, a proper audio setup is a very important thing in your toolbelt.
Summary
The list above contains things that are important in professional work, no matter if you work remotely or not. But when being on-site, you get many opportunities to minimize the consequences of not remembering about them. When you're not sitting in the same office as your client, you need to pay more attention to be active, transparent, and well prepared. At the end of the day, you may become as important to your partner as on-site developers, and that may bring value for both sides.