Remote work doesn’t have to mean working alone.

I have seen a number of articles recently that refer to the stages of remote work or maturity of your remote team as a linear progression to only one possible Nirvana. The Nirvana in question appears to be 100% independence, 100% asynchronous communication and no need to ever have any work-related human contact at all. Some companies even go so far as to explicitly not allow work related conversations insisting that all are in writing to avoid knowledge silos.

Whilst I understand the reasoning I find myself disagreeing with this conclusion. Yes – Being remote opens up the possibility of hiring from anywhere in the world, which means that there are the potential of round the clock time zones. Yes – being able to work whenever you want around your other commitments and family demands is an amazing benefit. And Yes the inevitable consequence if those are taken to the limits can lead to a conclusion that effective asynchronous written communication as the necessary means of communication. But it is not the only possible outcome.

For some companies especially those embracing full flexibility or round the clock time zones this may be desirable on some level. But I do not see it as the inevitable solution nor a desirable solution for all. Just like in the office there are different solutions depending on the circumstances.

How much flexibility is necessary?

Not all companies will have employees around the world or even want to. Many will already be in a single time-zone or a few closely connected ones so time zones are not an issue. And when it comes to flexibility how much do you really need? Is that flexibility worth trading human contact?
I used to work in an office, including drive time I was committing a 10-11 hour block of time every day. Now I am at home we adopt a core-hour system where we ask people to be available for meetings in a daily 6 hours window. Essentially if there is a team meeting booked in that time period we expect you to make every effort to be there, but this gives a huge amount of flexibility. I have more flexibility than I could possibly need especially in comparison to an office. I have gone from 11 committed hours to 2 or 3 per day with a lot of flexibility around that. Some may want more flexibility than this but if it means giving up human contact that extra flexibility comes with a very high price tag.

If I have sufficient flexibility and I don’t need round the clock time zones, why then would I choose a policy of avoiding human contact? In a pre-covid world it has become a widely accepted truth that co-located cross-functional teams are more effective and more productive. Agile prefers Individuals and interactions over processes and tools, and Customer collaboration over contract negotiation. I’ll happily trade some small loss of flexibility for a highly interactive and effective team.

Our History

Two years ago when I was asked to create an all remote Agile software development office I began with the assumption that this meant effective interactions and extensive collaboration.
The principles behind the manifesto spell out some essentials:

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

None of that supports asynchronous written communication. So you could say that we went against the crowd when creating a remote workforce as we prioritized real-time human-human interactions and rejected, where possible, written interactions.

We should be pioneers in creating remote Agile teams with a focus on co-working and collaboration.

The path less followed

Going against the crowd is always risky, but part of being Agile is that We are uncovering better ways of developing software by doing it and helping others do it. At the time I felt we were in a position to experiment, not with remote work, that was a commitment the company had made, but on how we implemented our remote office. I worked very closely with a like minded colleague and we came up with a plan for Remote Agile Teams. We decided that we would become pioneers in creating an environment for remote Agile teams with a heavy focus on co-working and collaboration.

We were already largely working as external contractors and not in a situation where we were working as closely as we would ideally like with stakeholders. Just like everywhere else, business-side stakeholders are busy and we were often limited to planned meetings and infrequent touch points. It became increasingly apparent that remote working actually gave us more opportunities to work closely with the business side. Perhaps not face to face physically but our interactions were more effective and more frequent than before. This increased interaction has led to far better outcomes. Because we were all remote there were fewer barriers to interactions with clients.

It was liberating to witness business-side representatives reduce their turnaround time on critical features. It was nice to no longer worry about booking our highly sought-after meeting rooms. And lastly, it was reassuring to realize that the focus should not be on face to face but on determining the appropriate form of communication given the constraints. With a newly established and excellent track record, we began reevaluating these principles and felt confident enough in our abilities to embrace the spirit of the Agile principle and even build upon them in a virtual office setting. 

But to do so we needed the right environment, an environment where business stakeholders and delivery teams could effortlessly work closely together daily. Real-time collaboration was key, and we intentionally removed as many barriers as we could to allow for effective communication channels. We relied on training, the right tools, and clear expectations to make this happen.

Is Remote Work compatible with our software delivery practices?

As we follow the Agile principles, we were heavily relying on practices like Pair Programming, Mob Programming and Test-Driven Development. We strongly encourage automated delivery pipelines and team ownership of the code and of the product.  In a remote setting, this posed a challenge as we had to consider how we would ensure effective communication and how to deal with connection lag. 

To be successful we needed tools and environments that enable our teams to continue with pair programming just as they did in the office. In the office, developers would typically share control of a single computer but with two keyboards and two mice attached. Remotely this posed a harder challenge as we also had to factor in remote communication and lag. The ability to share screen control, see the same things, and communicate clearly in real-time became a challenge. It was crucial to find the right tools for this as it was far more complex than simply sharing a screen.

There were other practices that we needed to support remotely such as stand-ups and retrospectives which are closer to meetings but have individual attributes that needed to be maintained in a remote setting.

Proximity, Awareness & Spontaneity

In looking for ways to enable remote work effectively we did a lot of research and experiments. In our research three terms came up again and again. Proximity, Awareness & Spontaneity these are not simply features of a tool, but words that describe feelings people want to have when using a tool. Software to support remote workers like this is not just a collection of functionality but a virtual environment where we are able to recreate human to human interactions. The best tools allow people to engage on an emotional level.  We added breakout rooms as a 4th pillar to round off the expectations we had for a remote environment.

Summary

We created a virtual environment where collaboration and co-working was enabled, supported and effective. Yet, we didn’t follow the ‘standard’ work-from-home model that most remote workers are used to. Our environment can be described as a flexible all day interactive workspace which expects ongoing, frequent, and sometimes sporadic communication. We created a sense of situational awareness of our environment and of our colleagues to allow for spontaneous conversations between our team members and between our teams and our business-side stakeholders. We feel close to our colleagues and have minimal barriers to interactions with them. We have an environment where pairing and other agile practices are not only supported and seamlessly enabled but are effective and productive. 

We are a workplace that routinely over-communicates, extensively collaborates, and empowers team members to quickly discuss a solution and make decisions. We are able to do this throughout the day and often with short-notice or no-notice. We have working agreements that support variations in time zones but also reflect a need for high-frequency interactive collaboration. We have tools and policies that preserve our culture but allow us to grow and evolve with new work techniques. 

In short we are Agile in a remote setting. We believe we are pioneering an alternative to asynchronous working and are hopeful that this is the start of a rapid growing trend.

Two years ago I was asked to set up a remote office with the intent to grow an additional option for our employees and clients. Today we have numerous teams working in this environment, and due to Covid we now have over 500 software delivery team members working from home but still together, we are based all over the USA and in the UK. The patterns we set up for 100 employees scaled seamlessly for the rest of the company So after two years working with remote Agile Teams we can confidently say that not only is it possible to have remote Agile teams, but that they thrive and are exceptionally effective.