Going Agile with a Remote Team

Recently, I logged into LinkedIn and saw a discussion headline they were promoting.  It read, “why remote working will die,” and man did people have a lot to say about that topic. The centerpiece of the discussion? Remote teams.

An Atlantic article examining famous telecommute-advocate IBM’s decision to build “agile spaces” and then to call its remote teams back to home base.  The article also referenced Apple and Google’s similar policies of office presence.  This created the general impression that large tech companies succeed on the back of high bandwidth communications and physically showing up.

And yet, it seems as though the death of telecommuting may be greatly exaggerated.  I won’t wade into the debate over the better approach here.  But I will say that the rise of the gig economy, the inexorable march of progress, and increasing globalization of work all seem to suggest that remote work will remain a mainstay of modern companies.

So let’s proceed under that premise, and move on to discussing the idea of agile software development.

The Agile Movement and Collaboration for Remote Teams

Almost two decades ago, a group of skilled software developers and consultants got together and produced the now legendary, “Manifesto for Agile Software Development” (since widely dubbed “The Agile Manifesto”).  It offered these four brief heuristics for software teams (emphasis mine).

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

It then followed with the clarification that, “while there is value in the items on the right, we value the items on the left more.”  Note the highlighting, and then note how much they value high-bandwidth collaboration.  You could say that collaboration serves as the backbone of the whole concept.

Like remote team work, agile software development isn’t going anywhere, either.  Over two decades, it has grown from that conference room with a handful of folks to the de facto software development approach, and a billion dollar consulting industry.  Both things are here to stay.

So let’s look at how to reconcile the two of them.  If you have a remote team, how do you successfully implement an agile approach?  And how do you do it without just throwing your hands in the air and giving up on the flexibility of remote work?

Understand And Optimize for the Difference

As I’ve already detailed, agile methodologies heavily emphasize collaboration.  Consider two popular agile methodologies: Extreme Programming and Scrum.  Development teams drawing from these approaches do things like the following.

• Pair programming.
• Plan work with sticky notes on a physical wall.
• Have a daily stand-up.
• Sit in an open-office style “bullpen” where all team members work around a table.
• Frequent, ad-hoc meetings around a whiteboard.

All of those things rely heavily on teams sitting together.  But while that may be sort of iconic, it’s not all that there is to agile software development.  It’s also about tightening feedback loops, adapting to change, and learning.   And you can do all of those things without a team that sits together physically.

You can use tooling to recreate some or all of the above.  And, while I’d suggest doing that as makes sense, don’t go so far as to force it.  Instead, accept the reality of the distributed team and look at how to tighten feedback loops, adapt, and learn in that situation.

Establish Collaborative Norms

Let’s move from the philosophical to the specific.  Embrace the reality of remote work and adopt practices that make sense within that context.  One of the biggest ways you can achieve this is to facilitate as much collaboration as you can.

For instance, try to create your remote teams such that members of the individual teams are in similar time zones.  From there, you can also establish a set of “core hours” during which team members are always available to chat.

You take this kind of thing for granted in a physically present team that works traditional hours.  Everyone comes in at 8:30 and leaves at 5:00.  But you can achieve a good bit of the same effect by just establishing a mutual agreement as to when team members can collaborate.

Schedule Periodic Get-Togethers (and include meals!)

When people cite the problems with remote work, lack of team cohesion always comes up.  And, that’s real.  Working alone, collaborating only over conference calls and Slack chats, doesn’t have the same feel as in-person collaboration.  Participants feel more disconnected.

And, while you can’t easily recreate the office experience with remote teams, you can still build camaraderie.  Have folks come to the office or travel to get together every now and then.  Make sure you go out for some meals, too.  Team members feel a good bit more cohesion when they’ve sat, laughed, and eaten together.  You can get an excellent return on this relatively small investment in terms of the team dynamic.

Use Telecom Tools for Agile Ceremonies

Another way to get the most bang for your buck with synchronous communication involves the so-called agile ceremonies.  If you follow Scrum, these are as follows.

• Daily stand-up.
• Sprint planning.
• Sprint demo.
• Retrospective.
• (Optionally) backlog grooming.

You may define others, depending on your particulars.  But regardless of which specific ceremonies we’re talking about, strive to have these live, using teleconferencing tools.  Use video.  You want folks to be able to see each others’ expressions and body language while this happens.  All told, this will probably only occupy 2-3 hours per week of time for the team.  So find a way to do this live, and reap disproportionate rewards.

Leverage Collaboration Technologies

Collaborative activities like pair programming go less smoothly when you’re remote.  There’s no doubt about that.  So you might not emphasize this as much with your distributed team.

However, you can also keep tabs on the latest technologies that help with this sort of thing.  For instance, Screen Hero (now part of Slack) specifically lets people share screens remotely.  It’s far from the only one, and these techs are constantly improving.  Other, non-live collaboration tools help as well, such as Trello, Slack, Google Docs, and ALM tools like JIRA.  Pick ones that the team is comfortable with and work out a good, nimble collaboration workflow.

These tools don’t replace sitting in a room together, per se, but they let you define a sort of collaboration that doesn’t try too hard to imitate that.  So try them out, and see how they work for your team.  Leverage them to the extent that they help, and check back in with them from time to time to see what improvements have emerged.

Operate as a Remote-First Team

Some of the best remote work success stories come from companies that bill themselves as remote first.  In other words, they optimize for the difference, as I advised earlier.  But they also go beyond just embracing the reality of remote work.

They define processes from the outset that make sense for remote teams.  From day one, they’re leveraging cloud services and automating build and deployment from end to end.  From day one, they’re making sure meaningful collaboration happens somewhere that it can be recorded for later reference.  And, from day one, they’re playing to the strengths of distributed environments, which, in the dictionary definition sense of the word, make being agile non-negotiable.

So if you want to go remote and you want to be agile, don’t go halfway, and don’t pretend that you all sit together when you don’t.  Understand that the lack of collocation costs you something.  But also understand that you can profit from it if you lean into it.