Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, celebrity chef-led humanitarian efforts. Yet Agile has started to lose favor. This has prompted us to get back to basics and start a series focusing on the Principles of Agile.

The sixth Principle of the Agile Manifesto reads:

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

Simple Thread is a remote-first company. We are based in Richmond and largely clustered around central Virginia, but we operate as a distributed team. On the surface, that puts us at odds with this principle.

However, if you dig a little deeper on the reasons underlying this principle, I think it’s relatively compatible with remote teams.

What It’s Not

As with the fifth principle, I think it’s helpful to start this review with a look at what the signers were likely rebelling against.

Specifications Documents

I like planning. Planning is essential for any project of even moderate complexity, but one of the key insights of Agile is that all plans will inevitably, inescapably go wrong. So let’s embrace that reality instead of pretending we can control everything. Specs are great to get a big picture and to make sure you have risks cataloged, a good plan to start, and so on.

But they cannot replace frequent collaboration, iteratively working through a problem. I’ve worked on projects with “BRDs” (business requirements documents) that were over a thousand pages, literally thousands of pages. The idea that everyone will read that – much less understand it – is insane, but it was common in the pre-Agile era.

Intermediaries

Another anti-pattern this principle is pushing back against is the once-common belief that developers should be shielded from the business users and customers. This is a focus of the fourth principle as well.

Monologues

It’s less common in 2021, where software has eaten the world, but a couple of decades ago, it was common for engineering to occupy a subservient position to the rest of the business. It’s hard to imagine now, I know, but it was once expected that engineers would take requirements from the business stakeholders and implement exactly what they were told.

What Remote Can Achieve

At the height of Agile’s popularity, team rooms were fairly common. This was a practice where the whole team sat together in one room, often around one large table, including the product owner and sometimes even the domain experts. As with most practices involving groups of people, I had mixed experiences with this. Some rooms were great; some were horrible. Most were both, at different points in the project, depending on a variety of factors.

Experiencing a good team room gives you a feeling for how effective and efficient face-to-face communication can be, and I think we can reproduce some of it in remote teams.

Synchronous Dialog

“Have we spoken to them about this yet? Or just traded emails?” If you work with me long enough, you’ll get tired of me asking that. I’m continually amazed at how people will exchange email after email, each more tediously worded than the last – with both sides clearly getting more and more confused or upset.

Then we hop on a call, and the whole kerfuffle is resolved in 10 minutes.

Nothing can replace talking through something together in real time, hearing their tone of voice, being able to ask for clarification in the moment, etc. It doesn’t need to be video, just a simple phone call often suffices. In some situations, a remote work environment can actually make this easier. I can hop on a quick call without worrying about disturbing my coworkers or anyone eavesdropping on sensitive topics.

Low-Friction

Chat tools like Slack and shared calendars make it easy to reach out without a lot of ceremony. I know some people get tired of the real-time barrage of chat messages, but I think that problem can be largely mitigated by company culture and shared team expectations.

For example, I encourage people to block off time on their calendar for periods of intense focus, and set their messaging status to Do Not Disturb. In a remote team with a flexible schedule, we need a way to see that a team-member is online and working right now. I don’t want to message someone about a low-priority item when they’re not working. I also want to see that someone is working but doesn’t want to be disturbed, for whatever reason.

A thoughtful combination of tooling support and team practices can make remote communication as low-friction as an in-person office space, while providing an environment more conducive to focus and flow.

High-fidelity Sharing & Collaboration

One of the great things about a team room is how easy it is to collaborate on one screen. You can just slide your chair over to your teammate’s computer and pair on some code, review a design, etc.

In 2021, we now have an embarrassment of riches when it comes to collaboration tools. With Slack, it’s ridiculously easy to jump on a huddle and share screens. Or tools like Miro and Figma make it easy to diagram and design together without even sharing a screen – and I’m not even talking about Google Docs and Sheets. That level of collaboration is just expected these days.

Lingering Disadvantages of Remote

As much as new tools of communication help, there are some aspects of face-to-face interactions that simply cannot be reproduced – at least not yet, not until we have a holodeck-style VR/AR solution.

Body Language

Even with a great Internet connection and the best video conferencing technology, body language is not conveyed well remotely. Part of it is just that our video is usually cropped to some portion of our head and torso. Part of it is that in a large group, each person is a small square of video.

But even if you had a huge screen and amazing camera setup, being on video makes people self-conscious. They don’t emote as much. They don’t gesture as much. They are less human.

Cooperative Overlapping

In face-to-face conversation, it’s fairly common to provide feedback and make small interjections and comments as another person continues to speak. You’re not really interrupting; you’re just showing that you’re actively listening and participating in the conversation – without trying to usurp focus. That can be extremely hard to do well remotely, especially without high-quality video. It often feels identical to interrupting; so people just sit silently, which can be unnatural and uncomfortable.

Osmotic Communication

This is a term I learned from an Alistair Cockburn essay, I think, but it’s just the idea that you can passively pick up knowledge from team chatter in the background. You hear some teammates discussing, for example, how they’re setting up the linter settings, and you absorb a bit of it, even if you’re focusing on your own work.

This is especially true in a team room setting, where multiple conversations can be happening at once, quietly enough that you can ignore if you want but loud enough that you can participate if you want. It can be distracting, but it can also be highly valuable. Either way, it’s nearly impossible to do in a remote setting.

Group Dynamics

One of the big things I miss from face-to-face communication is observing how other people interact. You’re in a big group meeting, and at a key moment in the presentation, you see two important stakeholders exchange a brief glance.

We’ve evolved to notice that glance and interpret it. If you know the folks involved and have decent empathy, you can probably decipher exactly what that glance meant. You can jump in to address their concern or make a point to follow up separately to discuss the feature, etc. You never get that with remote interactions.

Finding a Balance

We are a remote company, but we target clients within our region. That surprises some people, but I think there are times when you just need to sit across the table from someone and talk through a problem. Having semi-local clients makes that much easier.

As trust is built and we get to know each other, we think remote meetings can be just as good for most tasks, but when starting a project or meeting new client stakeholders, face-to-face meetings are often irreplaceable. If I ever doubted that, being unable to do kickoffs in person during the pandemic has reinforced this belief.

So I think I actually agree that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation, but I also think that there are undeniable downsides to this approach, downsides that often outweigh the benefits – both for the individuals, e.g., a daily commute, and for the team, e.g., harder to find time for deep work.

For me, it’s about finding a balanced approach. We might use face-to-face communication at strategic points in the process, but we leverage the many benefits of remote work for most of the routine information sharing and collaboration.