Rethinking Workflow for Virtual Teams

A new phrase came to me through the social stream: virtual team. I soon learned it’s merely another word for distributed team. Anyhow, this “new” term made think about my first virtual experience and how much I enjoy working like this, although I initially had negative preconceptions about the idea.

Here’s my attempt to summarize my experience of working in a virtual team.

I’m late to the party; I understand that. Although I’ve been working in the software industry for more than fifteen years, my first virtual experience was earlier this year, and it’s still ongoing. I’ve worked at places where the teams were collocated with some occasional individuals being remote, but not in the sense of being distributed or virtual. I was used to having daily standups and being able to lean over and talk to my colleagues sitting around the same table. Before actually working on a distributed, virtual team, my preconception was that it would be suboptimal to a collocated team. I was wrong.

My team is distributed over Krakow, Oslo, and Stockholm and also involves people in Barcelona and London. We’re not spread all over the world, but pretty much all over Europe. I wondered how we would do a daily standup involving people from all these different cities. Well, the answer is we don’t. Actually, we have very few synchronous meetings. I’ve seen other virtual teams trying to do daily standups over video, but to be honest, it doesn’t seem to work very well. Instead we rely more on asynchronous communication, using chat and GitHub.

Chat is where we tend to gather, and it can be loud at times—of course, not loud in the sense of having a noisy conversation in an office space; it’s just where most communication takes place. Using a text-based chat gives you the option to dig in now or dig in later. If someone really needs your attention they can send a notification, but that feature is used cautiously. People not directly involved in software development may think this is weird, but it’s out of respect. Disturbing someone else’s concentration comes with a cost.

Remoteness has obvious drawbacks. Sometimes I really wish for face-to-face communication. Video conferencing can overcome this longing a little, but not entirely. Notification fatigue is also a reality when most communication happens electronically. Going to bed with an empty inbox just to wake up with a hundred new messages can be draining.

Infrastructure also becomes a challenge when working on a distributed team. We’ve overcome that by simply not having any infrastructure. There’s no network, no VPN, no firewall. Instead, everything is in the cloud. This also means “work” is no longer a place. All you need is a computer and an Internet connection, and you can work anywhere.

I know no better tool for code than GitHub, regardless of whether you work in a collocated team or a virtual one. We store all our code on GitHub and publish any changes to it as a pull request. The pull request is a change set published on a webpage where your colleagues can make comments and collaborate. GitHub made code reviews practical.

It also supports issues and milestones, but it’s somewhat limited in that there’s no way to order or group milestones by dependencies. So we invented the Stoneboard, where dependencies between milestones are visualized as a graph. With the dependency graph it is clear to everyone what work is most important at any given time, and we usually pull work in that order.

The use of GitHub for almost everything also means near-total traceability. We don’t have formal traceability requirements—we’re not a bank, and we don’t make medical equipment or rockets. To us, traceability is just to make sure few things are getting lost or forgotten.

Management does what management does: meets with customers and users, and plans for the future. Our management isn’t overly concerned with dealing in developer work. Most developers work full-stack—front end, back end, and operations. Basically, anyone can do anything, and we are allowed to do so. We even have a full-stack product manager. Our product managers gaze into the future while at the same time keep the prioritization of current development clear.

We pick work that is most important or that looks the most fun or challenging—often, it’s a combination of the three. Developing and maintaining a fairly complex distributed software system requires feedback loops on many levels; the team is driving the product rather than merely developing it. The level of autonomy the team has stems from this premise.

I think my main takeaway from working like this is that things that are in the way for a collocated team have to be eliminated in order for the virtual team to work. With that in mind, what is your team doing that would not work so well in a virtual setting? What would it mean to eliminate those things? Thinking about these answers might make you look at your work differently.