Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Does Remotely Mean Worse?

DZone's Guide to

Does Remotely Mean Worse?

Despite its growing prominence, remote work can be seen as a less efficient way of working. In this article, we ask why that is.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Editors Note: Originally written by Mateusz Fligier and shared with his permission

In an earlier article on the NearshoreIT Blog, my colleague Radek Okarmus reflected upon the role and image of IT companies and mentioned the difficulties of building trust with the customer, especially on the Polish market. I would like to take a closer look at this issue, as I get the impression that this is often the reason behind delays to, and sometimes the cessation of, software projects.

One of the most common indications of a lack of trust is a reluctance to cooperate remotely. In my opinion, this is a somewhat paradoxical phenomenon. We live in a time of technological development unprecedented throughout the history of civilization. We can conduct a video chat from Munich or London with a cousin from Australia, or show our parents in Poland photos of our trips from Canada, or study via courses taught by lecturers in the United States without leaving our home in Manchester. Moreover, doctors who are hundreds of kilometers away from the patient can consult and even perform surgical procedures.

So why would a potential customer, on hearing that a developer could work for him remotely, respond as if someone was trying to get him to dive head-first into an empty swimming pool?

Where does this need for control, which may be illusory in practice, come from? Why assume that remote tasks must involve lower quality, as well as security risks? The paradox is that often the same person shares his private network and confidential matters in good faith that no one will use this data against him, yet prefers traditional forms of carrying out projects at work. But technology can carry a threat in both our private and professional lives, because eavesdropping, tracking, or data theft are just as commonplace as the positive examples mentioned earlier. Technology is ethically neutral, but the way it is used is determined by people. Security is also a product of the technologies, rules and good practices used, both privately and professionally. The same is true both remotely and on-site.

But returning to the topic at hand – an unwillingness to work remotely is most often explained by the following arguments:

  • Integration of the team is necessary.
  • Real-time communication between team members is required.
  • Workers are physically present at headquarters out of habit.
  • Management is unwilling to run such risks.
  • It has been tried but didn’t work out.
  • We don’t want to lose control of security.
  • It’s important that people are connected to us.

But let’s look at the facts. Around 70-80% of developers at JCommerce work remotely for clients. Interestingly, these clients are mostly foreign companies: from Switzerland, Germany, and Scandinavia. How is it that cooperation proves successful, despite the tyranny of distance, the rarity of face-to-face encounters (due to the optimization of flight and accommodation costs) and the need to communicate in a foreign language? Communication works smoothly, the quality of service is high, and problems are solved as and when they arise.

It is also important that the customer does not have to take care of office space, furniture, and equipment. Security, which is of vital importance, is ensured through the appropriate management of access and permissions (in accordance with previously agreed procedures). In some cases, the client passes equipment on to the developer, including the computers they administer according to the company’s standards. Remote work is generally not a security risk, at least no more than on-site work.

Finally, we come to the so-called ‘soft’ issues, such as the problem of employee integration. The brutal truth is that if the project is badly run and such factors as chaos, lack of documentation, lack of consistency, or a bad working atmosphere arise, then even the physical presence of team members in the office will not change anything. Developers, whether they are permanently employed or just on a contract basis, will look for other options, and will soon find them in today’s business climate. Conversely, a good atmosphere and efficient communication within the project can also be achieved from a distance, merely by using the appropriate tools and techniques of team management. The conclusion is that the integration of workers and the possible problem of rotation within the project are not in any way dependent on geography.

In summary, it is worth knowingly leaving one’s comfort zone, abandoning the stereotypical limits to development, and exploiting the benefits of remote work, which would mean:

  • No office overheads or cost of commuting.
  • A broader choice of specialists (we have developers from many cities, even countries, at our disposal).
  • Better quality work – here the phenomenon of scale comes into play, i.e. an employee of the service provider, working remotely, can more easily and quickly consult on the problem with equally or even more experienced colleagues from his or other teams.
  • A good IT service provider will also have no issues with allowing the customer to test the remote work option in practice (e.g. a trial period with the possibility of terminating without notice and then proposing a different specialist).

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
team building ,agile ,remote teams ,agile teams

Published at DZone with permission of Kamila Łopińska. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}