Drawing: Nodes in a cluster, microservices diagram, or your new organizational chart?

Developing and delivering software remotely has been a growing trend throughout the last decade. Still, colocated teams, physical meetings (often involving geographically dispersed teams, but held in an office) and traditional management were the dominant work setup. However, due to recent events, the “digital” or, more precisely, “remote transformation” has been rapidly accelerated.

Let’s look at what it takes to successfully deliver a software project that is developed remotely by a distributed team.

Compared to other industries, software development is especially well suited to be done in a distributed manner. A software project rarely really requires physical presence. Unfortunately, this does not mean that running software projects is easy, or easier than running other types of projects remotely. You can do it, but it still requires effort.

For a number of people, working exclusively remotely is brand new, with brand new challenges. Hence the questions:

• What are the traps to look out for when managing remote software development?
• How to organize work of a remote software development team?
• How to make sure everybody is on the same page, and works efficiently?

Our perspective on remote work

Before we dive into details, let me first explain why I think our experience from SoftwareMill might be relevant to the questions presented above. Since its inception in 2009, SoftwareMill is a remote-only, fully distributed company. That is, we don’t have an office, and I doubt that this will change in the foreseeable future (though, never say never! :) ).

Our mission is to deliver systems, which help our clients scale their business through software and technology. We’ve grown from an initial team of 4 to over 60 through the years, and have successfully delivered a number of projects - all of them remotely. Some of them are on our portfolio page.

Our team is truly distributed (mainly across Poland), and the same applies to our clients. The majority of them are from the US, UK, EU, but we have also done projects in Japan, South Korea, Australia and South Africa (and some in Poland as well).

In a way, much less has changed due to the covid-19 outbreak in our daily work, compared to teams which have been urged to become fully remote overnight. We’ve been working from our homes or co-working spaces for a number of years; we’ve been using various synchronous and asynchronous communication tools daily for a number of years as well.

That’s why I think we have credentials in the area of remote work and distributed software project development. At the same time I feel we could help others with transitioning to the remote model by sharing our experience.

Lessons learned when managing remote software development projects

1. Implement good communication rules

You’ve probably seen this one before, but I’ll reiterate. Communication comes first and foremost. It’s always better to overcommunicate, then undercommunicate. Of course, overcommunication over time leads to frustration and inefficiencies. However, once the communication already happens, it’s easier to tune it down where needed. When there’s silence - no communication - you don’t even know what to tune up!

The same rule applies to co-workers, business partners and clients.

Whenever you are in doubt, ask.
If you have a question on how a particular feature should work - ask, don’t assume (the assumed solution would probably be incorrect anyway).
If you’re not sure what are the priorities - ask.

Asking is just the first pillar of communication, and in reality it applies the same both to stationary and remote work setups. For more information about how our fully remote communication setup works go here.

Be on the same page with your remote team

The second are regular status updates. It’s probably not obvious for other team members what everybody else is doing. A regular update helps to keep everybody on board. With remote work setups, where people are far away (physically) from each other, a lot of casual communication might be lost. Make up for it by being clear on what you are working on. These might be standups, Scrum meetings, synchronous or asynchronous updates, using text or voice, or whatever else works for your remote team.

You might have different status updates held with the client, and others held with the team: their scope doesn’t have to be the same. The client doesn’t necessarily have to be interested in the technical details of the solution that is being created, while not all developers need always to be present when demonstrating an incremental update (however in most cases this is in fact desired and beneficial). If you’re looking for particular collaboration tools that could streamline communication we have a separate article about Tools that make work faster.

Make up for the non-verbal aspects of communication

Finally, remember that communicating remotely is much poorer in terms of signalling: it’s either just text/text+voice. Even with video calls, a lot of non-verbal communication is lost. Misunderstandings and conflicts will arise, and are inevitable. In such situations, always remember about the remote context.

Assume the best of the other side; text is very “dry” and can often be easily (and unintentionally!) misinterpreted.

Of course, nothing’s for free. Distributing a team creates communication overhead, and communicating more takes more time. However this is time well spent; it’s better to discuss a solution for half a day, than spend a week going in the wrong direction, only to discard all that work later.

“A remote team may be less productive than that same team if it were co-located, but may still be more productive than the best co-located team you can form.”
Martin Fowler, source

2. Understand the business side of the project

Understanding the client’s business is crucial in any software project, be it remote or stationary. Entire team: scrum masters, project managers, developers: all of these people need to have a good grasp on what is the idea behind the project, what kind of problems does it solve and what are the business benefits to the client.

Engage the client in such business-orientation meetings; let the developers ask questions about all the project details; there’s nothing wrong in wanting to find out what are the business processes that should be automated.

Quite often, these sessions with the client end up in developers giving substantial input to the goals and structure of the project. Of course, we need to keep in mind that the client is the expert in their business domain; there’s no questioning of their authority in that area. However, remember also that it’s the developers who are the experts when it comes to technology.

It’s quite natural that when business talks to development, this exchange of perspectives can help to discover how to improve the business using a particular technical solution. Clients may simply not be aware of how a problem might be solved; same as developers are probably not aware of the problems the client is having when running their business.

3. Facilitate better remote meetings

Meetings have been demonized as the single biggest waste of time during project development, but despite that, they are still happening! And there’s a good reason: regular meetings are needed; or rather: good meetings are needed. Apart from peer-to-peer exchanges, meetings are crucial in propagating the understanding of the business, in communicating project status and current goals.

Designing good meetings is an art form, and in no way I’ll even attempt to give a recipe on how to run a meeting successfully. Bookshelves can be filled with advice on that topic! I’ll resort to just three main points:

• a meeting should include the minimal number of people, but not less
• prepare for the meeting; be respectful of the time of others 
• keep the meetings short

The last point is especially important in a remote meeting. A long remote meeting is even more energy-draining than a long colocated meeting. You need to stay focused in front of your screen, with your headset on, with no other people around. Not to mention all of the trivial distractors: it’s way too easy to go browsing the internet when the meeting is getting long and boring.

That’s why remember to properly prepare and schedule meetings beforehand, keep them short and focused. If you do need to make a long meeting, make regular pauses so that people can refresh, stand up and walk, even if it’s only around their houses a couple of times. Then, start anew with new energy.

4. Be agile about agile

Most software projects nowadays are done in an “agile” way. Sometimes this doesn’t have much to do with the agile manifesto, but still there’s a number of practices that have been developed over the years, which we might choose from when running the project.

Not all of them translate easily and directly into a remote setup. Remember that remote has its own challenges, but also its own benefits. Whatever your preferred method of working was, remember to be agile about agile. That is: be open to change. Maybe you’ve been used to doing an all-day hands-on whiteboard planning session at the beginning of the sprint. This might work great in a remote setup as well; but maybe it’s a good idea to try something else, shorten the planning, make it more frequent, transfer to a more Kanban-style of development.

Agile is about being elastic and adaptive to the changing situation. One such change is going all-in with remote! That’s why the same as we adapt to the changes requested by our clients in the software we develop, we should be adaptive in the way we structure the development process itself.

5. Transform remote work with transparency

For many people, especially higher on the management ladder, one of the main problems will be the perceived lack of control over their remote software development teams. There are various ways circulating on how to make sure that your software engineers are actually working, ranging from funny to creepy. Each such solution is usually paired with a “hack”, making it yet another annoyance rather than anything useful.

Maybe it’s a utopia, but I don’t believe in any of such attempts. Especially in the software business, which in a large degree is (still) a creative process. Creative processes are hard in being overseen and controlled. Often, the best thing a manager can do is step away and let software developers do their thing. Same as in an office, when working remotely, people have better and worse days (especially in today’s stressful situation). Sometimes you’ll catch the flow and implement two features end-to-end during a single day. And sometimes you end up contemplating two lines of code for 8 hours straight, without much progress.

The main tool which you can employ in remote project management is transparency. This might be implemented on many levels. For example, for a start you might be transparent about the status of the project. What is it that the client is saying about the project’s progress? Are there any problems when communicating with the client? What are the client’s expectations? But also going the other way: sharing with the client the concerns of the software engineers; showing what they think might be a better solution to a particular problem; allowing them to ask questions.

This might be brought further by being transparent about the sales process, overall company condition or even finances. For example, in SoftwareMill we have a fully transparent organisation. That’s not to say I suggest everybody to establish their company that way; just that it is possible. And believe me: being transparent about everything (finance, sales, marketing, development) is truly liberating.

Secrecy, keeping secrets, tracking “who can know what” really weights down on you. It’s an exhausting process, and removing at least some parts of it makes things simpler. Which is needed in these otherwise complicated times.

On the developer side, transparency might translate to being open on what it is that you are working on; not minding questions on the status of a task, as well as inquiries on why they chose a particular solution. Remember that the asking side probably has good intentions and is genuinely interested in your work!

However, transparency has its limits. Of course, broadcasting your desktop to everybody is transparency taken a couple steps too far, and in a totally wrong direction. Working with this kind of oversight must be really uncomfortable and unproductive.

Transparency means that if somebody wants to know something about the project, they can ask, and you’ll try to explain it to the best of your knowledge; or delegate to somebody who knows better than you.

6. Trust your remote teams

Trust is very much related to transparency and control. If you don’t control your remote software developers, how do you know they keep working? You don’t, you trust them. But what if somebody is slacking?

Transparency has an answer to that: in a transparent project/organization, it’s very hard to hide the fact that you aren’t really doing anything. Either the team will notice, and try to do something about it (remember that a slacking person is an obstacle to the entire team’s progress! Trust the team, that first they will try to fix the situation themselves). Or the scrum master/project manager/project lead will notice, and act upon it.

If you’ve found yourself suddenly in a remote-work setup, you can either go the controlling, or the trusting route. I’d suggest trying the “trust” route first.

There are also other benefits to trusting your team, other than not having to control them all the time. For example, you can try to include the development team in the project management. Be transparent about the project’s condition, and trust the team that they will run at least some of the aspects of the project themselves. You might end up with a shorter communication pipeline, more efficient work and better motivated developers. If you’re curious to know the developers’ perspective on trust and remote work, read this Remote developer interview with our team members.

Summing up

The above is a loose compilation of what I consider important factors when developing a project remotely. It worked for us throughout the years; maybe it will help your organization as well.

This is not to say that we didn’t and don’t have our problems. We do, but we also constantly try to solve them. It’s an ongoing process, one which I doubt will ever end. We’ve gone through a number of tools and ideas on how to best structure remote work, and while our solution works well, tomorrow we might come up with a better idea to try.

Remote work brings a new level on which you can be agile: not only in the way you run projects, but also in the way company communication and work setup is organised. By definition, there’s less human contact when working in a distributed team, and this must be made up for in some way. Engaging developers in all stages of the project, making sure everybody understands the business and that everybody can always ask a question are some ways of making remote software delivery work. Don’t forget about building personal connections and the social side of working together, as well!

What is described above is also part of our journey towards self-organizing teams, and creating a truly self-organizing company. While a truly self-organizing company might be impossible - the company leaders will always have some important role to play - we might try to get as close to that goal as possible. In our experience, remote work and self-organization go hand in hand in a number of aspects.

Hopefully we’ll all soon be able to return to our regular lives, without a developed fear of remote work! Remote work works - as the example of SoftwareMill (and numerous other remote-first companies) shows.

A guide on how to communicate, collaborate and deliver in a remote software development team

Find out how to improve your communication, project’s setup or remote processes in the free Remote Software Development eBook.

• 8 lessons by SoftwareMill developers on how to make the most out of remote work
• Full setup of all our communication tools and channels
• Best practices for delivering software by a remote team
• Tips for taking care of culture of a remote development team

Download here.