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.

Virtual Co-Development Opportunities

When talking about the virtual office or remote working in general we often find ourselves comparing to a physical office and talking about how it is almost as good in a variety of situations. Or highlighting the indirect benefits to the business such as the ability to focus less time commuting, the improved happiness of employees, and lower turnover. These are all great but they are not easy benefits to convey to customers.

There are a few areas where a ‘virtual office’ is better and I previously described how we could be more Agile by being virtual but over the last few months we have discovered that we can solve some really fundamental business objectives for our clients without compromising on any of our values, standards, or profit margin.

Example case study

As an example: we have a client that historically outsourced much of their software needs to third parties, the result for them is a mismatch of tools that do not integrate well and have varying standards of quality. They also have problematic and often costly support models and the overhead of dealing with a myriad different vendors.
As a result they have now adopted a policy of owning and supporting their own tools and bringing back in house the tools that had previously been outsourced.

But this raises a number of issues. There are four issues in particular with this situation that they are seeking to resolve. I see these issues as being common to almost all engagements and all companies when they have identified a need for using an external software consultancy.

Bandwidth

Bandwidth: their IT department has limited capacity, the teams can only do so much and there is a lot of work to do. There are only so many people available to do it and they have a limited spectrum of skills. Conversely the value of the projects to the organisation is vast. However, limitations on hiring, head count and domain knowledge acquisition mean that the cost of delay justifies using a consultancy to bolster the capability.

Cost

Cost: The work could be outsourced and ownership retained if a consultancy firm is employed. After a period of knowledge handover the internal teams could support the software after the project is complete. However, hiring a large team of consultants is expensive, coordination and communication can be difficult. Integration with other tools at the client site is complex – often slow and painful, and knowledge handover is time consuming, all of this is very costly.

Outsourcing to a third party may be difficult from a budgeting perspective. Bespoke software projects are notoriously difficult to assess scope and cost and it is not unusually for projects to exceed initial estimates.

Knowledge

Knowledge/Expertise: The internal teams may not have the knowledge and experience necessary to do all of the work, especially in specialist areas like mobile application support and so it is often necessary to hire experts and then transfer knowledge to internal employees. Knowledge handover is time consuming and when done at the end of a project is often incomplete or doesn’t fully sink in. Risking later failures or expense.

Trust

Trust – Generally software is pretty opaque and so when there are problems or delays or unexpected work, or tasks that are more complex than anticipated clients are naturally anxious as it is hard to tell the difference between genuine problems or mismanagement. Trust is often unspoken and hard to rationalize, particularly when you are paying large sums of money for what is often a black box. It can sometimes seem like writing a blank cheque and hoping. Much of this is the nebulous nature of software and the every changing environment but when you are paying the bills this is a hard pill to swallow.

Co-Development

One of our common offerings is co-development this will generally resolve some of these problems.

Bandwidth: We can offer a co-development setup where we intermingle part of the client’s development team with our smaller team and work together on a project essentially half a team each. This is a great solution for this situation, the client retains ownership of the software, they are already working in the client’s IT environment with their employees, so integrating with other systems and teams is easier. Because the client is not committing a full team to the activity their bandwidth is maximized, they could essentially double their capability if they split all of their teams this way.

Knowledge: This method enables the consultancy to supply the expertise and the client to supply the domain knowledge. Knowledge is transferred throughout the project with no need for a clumsy handover period at the end. Knowledge gained by doing the work is far more valuable and reusable. It also shares knowledge of practices and processes in addition to the knowledge of the software.

Trust: By using a co-development effort it becomes a partnership, your team is part of the solution so you have much more insight into the situation so much more confidence in what is being reported. If there is a problem that is more complex than anticipated your own employees are engaged and able to offer transparent and unfiltered insight into the situation giving you far greater trust and awareness. As your team are part of the decisions there is less second guessing and more accepting that the decision made was the best with the information we had at the time. This is not a substitute for good planning and good management but it removes the nagging uncertainty when using a third party.

Cost: The main problem with this model is that unless the client is very close this becomes expensive and inconvenient. The development team needs to be prepared to work away from home for extended periods, there is a lot of lost time for travel. Generally speaking people do not enjoy working away for long periods and of course the client now has travel and accommodation costs on top of consultancy rates, making the service very expensive.

We essentially solved three of the problems but made the cost problem worse and added the complication of inconvenience to the employees. It limits this solution to those where cost is less of an issue or those local to the consultancy.

  • + Bandwidth:
  • – Cost & Inconvenience
  • + Knowledge
  • + Trust

Virtual Co-Development

Virtual co-development enables us to solve all of these problems. A Virtual co-development model brings all of the benefits of co-development listed above but by the virtue of being virtual there are no travel or accommodation costs, there is no time spent travelling. This cuts out a significant chunk of the cost with very little in the way of consequence.

The virtual nature also makes the team more accessible to the client and the home office, it essentially brings everyone closer.

Shifting to work virtually does come with a slight adjustment period and there are a few technical hurdles to be able to share screens and get access to client’s software environment but these are fairly trivial and common problems and access to a a VPN will resolve this generally and as most companies are already prepared for employees working remotely some of the time it is rarely a complicated request.

  • + Bandwidth
  • + Cost
  • + Knowledge
  • + Trust

Magic Bullet?

It is rare to be able to offer a solution that seemingly ticks all the boxes but this seems to me to be one of those rare opportunities where we are able to offer a better service for less cost, with less complications and without compromising profit margins, it really is a win-win situation.

The partnership style of this also reduces complications over scope and budget, it can be more easily budgeted for. By the partnership nature of the work budgets for the outsourced elements can be very accurate as they can be for a fixed duration – rather than arbitrary scope set before the product is fully understood or nebulous outcomes. There is no risk of being forced to extend because of incomplete work or scope change. The ongoing partnership means that the internal team can continue at any time with little or no hand-off. It becomes a much more clean and simple contract.

This model won’t suit everyone and is not ideal for all clients but for those with similar needs to the client above I feel this is a golden opportunity and one where being a virtual team is a clear and distinct advantage.

A 3-pipe problem

Sherlock Holmes was a master of deductive reasoning and problem solving, rarely was a problem beyond his capability. However, every once in a while he encountered problems that required a greater level of consideration, it would stretch his mind to it’s limits and required him not to be disturbed for an extended period, he described these as 3-pipe problems, he would need the time it took for him to smoke three pipes.

IMG_0640

I am no Holmes but I have the joy of a 3-pipe problem to immerse myself in. I have been asked to lead an endeavour to create, build and run a virtual office comprising of cross-functional teams that create software. The challenge is to grow an office but maintain agility, retain our company culture, and have the teams happy and engaged. Oh and be profitable too.

Where I have seen remote work successful in the past has been where there were clear tasks assigned and collaboration was a minor element of the work. My observations of many remote workplaces is that they focus on individual contributions, collaboration is asynchronous and there is a heavy overhead of management assigning tasks.

What I am envisioning is a workplace where the team is self organised, and whilst there is likely an increased element of asynchronous working it will be alongside effective collaboration. I see my role as identifying healthy boundaries that enable collaboration and creativity.

36509555 - remote work or global wi-fi internet connection

Communication

Naturally communication is key, just as it is in brick and mortar offices, but when we are face to face we have a lifetime of skills to rely on. Instinctive awareness of body language, sensing mood and tone, not to mention touch – hand shakes and physical contact create bonds we don’t fully understand.

Remote teams communicating effectively is far more complex than simply joining a webex. I see the ability to communicate and collaborate as the number 1 challenge of this role.

Why this?

As an agile coach I strongly support the Agile manifesto (alongside Lean, ToC, and Lean Startup) and the manifesto favours individuals and interactions over processes and tools. It also advocates face to face communication. And yet I am taking on a role that is putting barriers between people and pretty soon I’ll be talking about how processes tools are vital for enhancing individuals in their interactions.

So why take on a job that seemingly flies in the face of this? The answer is twofold, First I believe the manifesto is a mindset for guiding teams in improving their way of working to get better at delivering software. I believe we can adhere to that mindset in this environment, I don’t see a conflict. Secondly I think that the focus and scope of the manifesto didn’t consider the larger picture and the changing state of the workers needs. Face to face is better – no argument from me, but it comes at a cost. We need to weigh up what is lost and what is gained from remote working and decide if what we gain is worth the sacrifice and I think with the right attitude, training and tools the desired outcome of effective collaboration can still be achieved and achieved in a way that is better for many team members.

What is more, I think this will be one of the most challenging coaching roles I have faced. Just like teams, coaching is far more effective face to face. The coaching may take on a different dynamic but I still very much see this as a coaching role.

Processes and Tools.

I warned you! To have effective communication and collaboration in a virtual workplace processes and tools are vital ,and are a prerequisite to the individuals and their interactions. But I don’t see a conflict here, in face to face communication there are processes and tools, we just don’t feel the need to mention them as they are natural to us.

Don’t shout, don’t mumble, don’t interrupt, pay attention, look at the speaker, be respectful. Lots of processes and a lot of non-verbal communication. And just watch for hand gestures or pens on post-it’s or whiteboards these are all tools, we hardly consider them that way and we certainly wouldn’t object to any of those processes or tools, they are necessary for our interactions.

In a virtual world the need is the same but the tools are different, tone of voice and body language are harder to decipher, so we need to be more attentive and more explicit. pen and paper are replaced with online collaboration tools, shared screens, electronic gestures and Slack messages to clarify misunderstandings.

IMG_0639

The scope of the task is daunting but I so excited about this. My employer is already a leader in Agile software delivery, this is the chance to demonstrate that we can be agile about flexible work environments without sacrificing what has made us successful: collaboration and self-organization.

This blog will continue to be Agile focused but I’ll also share some of the experiments as we discover what works for us.