5 Ways to Drive Down Friction When Distance Separates Your Team

Most businesses by now have heard of, attempted or succeeded developing software using Agile methodology. No one will argue its adoption has been among the most impactful changes in the world of software development in the last 10 years. It has become the defacto method of conceptualizing and delivering beautiful, working software within a given timeframe. Shippable functionality is delivered every two weeks.

Cost-conscious businesses (and really, what businesses aren’t) have also been eyeing the benefits of remote teams with the ferocity of an Olympian defending his title.

“Individuals and interactions over processes and tools” is a core tenet of Agile. It is realized through practices like co-location, pair programming and daily scrum check-ins. Herein lies the question modern businesses must ask.

The Agile Manifesto also goes on to state the principle that more specifically addresses co-location of the development team: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

So, if face-to-face conversation is important in Agile methodology, and teams are increasingly becoming more distributed, then is “remote Agile software development” an oxymoron?

No. In fact, they are highly compatible with some adjustments made in each environment.

Balancing the here vs. there dynamic of Agile distributed teams

While there have been lots of new tools and languages, I’ve long thought the most substantial gains in software development could be achieved by helping software development teams learn faster and communicate better. Communication is an obvious challenge for Agile distributed teams working across an oceanic divide. There are a variety of reasons teams are split up geographically: work-from-home policies, employees working as part of a company that has grown through acquisition and now finds themselves managing multiple locations or use of offshore talent.

5 strategies to overcome distance for distributed Agile teams

1. Continuous integration

Continuous integration has been a best practice of high-functioning product development teams for years. The benefits of keeping the source code in a continuously “working state” improves both efficiency and productivity. Continuous integration is even more helpful when team members are distributed geographically and may have different working hours due to time zones. With time/distance as a barrier, teams can’t always communicate in an ad hoc way to diagnose source code build problems or branching and merging issues. Despite this, great build discipline maintains efficiency when communication isn’t easy.

2. Travel to meet your distributed Agile teams

Face-to-face (screen) conversation with your team can only go so far to build rapport and camaraderie. In-person visits to work with distributed team members always provide me with insight that I couldn’t have learned any other way.

Traveling to whatever location you choose to work with, and traveling there often, is a fair price to pay for more long-term cost-savings.

I once worked for a software product company that was going through a period of extreme growth. We decided to grow a team in Santiago, Chile to help us manage scalability challenges. We were about 6 months into the relationship before I decided to visit the team in Chile. The first thing I noticed upon arrival was a row of about 10 workstations where new developer candidates were watching training videos of our product.

I didn’t know these videos existed, and I came to find out that our partner had created a sort of “boot camp” to train new technologists. I quickly realized that our partner had become better at training people on our product than we were. The partner’s greatest challenge was adding technical talent to the team, so they solved that problem.

I immediately took the same training concept back to the US team and put it to work training our new developers as well. Travel not only helps solidify relationships, it is always enlightening.

3. Lean into the social aspect of software development

The most effective distributed Agile teams rely on accountability at an individual level and trust at an organizational level. While remote can’t reside in the same physical space, it is very possible to create an online community with the goal of knowledge sharing. This collective community (however it’s created) promotes things like:

• Collective code ownership
• A culture of learning
• An expectation of accountability
• An environment where interactions among team members happen voluntarily

Make it the team’s responsibility to find the most effective ways to share knowledge, and then support them.

4. Re-assess requirement depth

With any development team, one of the best ways to ensure an efficient development process is to drive it with consistent and clear requirements. Agile principles encourage that you use “just enough” documentation (typically in the form of user stories) when it comes to requirements. Know that with distributed teams “just enough” might mean more documentation than just a simple user story to take the place of the face-to-face conversations that are possible with co-located teams.

Beyond user stories, I’ve found that focusing on high-value requirements including user experience, story boards, wire frames and graphical design often are an efficient way to tie many user stories together. This method also conveys the breadth of context that only seems to come with visual input.

Think of this kind of work replacing what you might normally do on a whiteboard with a co-located team. Another valuable way to augment user stories is to include explicit test/acceptance criteria. This not only helps the developers understand how a feature is intended to be used, but also helps the test team tremendously.

5. Test available collaboration tools

One thing that has greatly improved the productivity of distributed teams is the widespread use of good, reliable collaboration tools such as Skype, Google Hangouts, Slack and others. Instant messaging has nearly replaced in-person collaboration (even when people are in the same office).

Most collaboration tools now provide a visual status to indicate a user’s availability at a glance. And when working with teammates whose first language may not be English, often chatting is a more comfortable way to communicate.

Another feature of most good collaboration tools is that they allow a natural “escalation of communication”. For example, what starts as a one-to-one chat, can evolve into a one-to-many chat, then a voice call, or a video call, then screen sharing and even collaborative content composition.

Putting it together

In many cases I find that geographically distributed development teams can be as productive, or even more productive, than co-located teams. Agile principles encourage focus and maturity on several critical aspects that otherwise add “friction” into the development process. Factoring in geography, this focus is further intensified. These teams simply don’t have the option to fall back on face-to-face interactions to remedy normal everyday challenges such as fixing a broken build, or asking for real-time clarification on a requirement. Reducing friction starts at the beginning of a process adopting a set of principles beyond the Agile Manifesto to accommodate a remote workforce. The future of software development is here — and it’s distributed.