This is part two of a two-part series on tools and practices for maintaining a healthy and effective remote team. In part one, I discussed infrastructure and tools for remote teams. In this second part, I’ll be focusing on day-to-day practices and attitudes. As with part one, this advice is not only for remote teams — you’ll find it beneficial even if you work on a co-located team.
The central tenet of maintaining a healthy and effective team is to make morale, cohesion, and communication a priority. The tips below touch on this core theme, but it’s such an important point that it should be explicitly singled out and emphasized:
Team morale, cohesion, and communication are vital for a remote team.
It’s vital, but it’s also challenging. It takes considerably more care, effort, and attention with a remote team than it does with a co-located team. Our brains crave human connection, and that need is more easily satisfied when we interact with each other face-to-face. But it’s certainly possible to meet that need on a remote team. You just need to be more deliberate about it. Don’t leave something this important up to chance.
Gather ’round the watering hole.
An easy and effective way to help maintain team morale, cohesion, and communication is to establish a virtual “watering hole” where team members gather to ask questions, make announcements, send out reminders, chat about their weekend plans, share interesting articles, post funny images, let off steam, and just generally be human together. Depending on the size and personality of your team, you might prefer to mix business with leisure, or to establish multiple channels to keep things more organized.
A persistent chat room (like HipChat) is a great tool for this, because people can come and go without missing anything. There will, of course, be times where you really need to focus, and having a chat room open is just too distracting. Fortunately, with persistent chat, you’ll be able to log back in later and catch up on all the latest jokes, GIFs, LOLcats, and other mission-critical resources.
Pair by default.
When you start work each day, you should assume that you will be working with someone as a pair. There will be times when you have a good reason to decide not to pair on a particular task, but that should be an exception that requires justification. Conversely, you should never have to provide justification for pairing. Pairing should simply be the default mode of operations.
Why? Besides the product quality gains that you get from pairing — two heads are better than one, and all that — working together helps maintain team morale, cohesion, and communication. Being human, there will be days when you’re not feeling so enthusiastic about work. If it takes a special effort to pair, it will be too easy to push it off, fall out of practice, and gradually drift apart and become isolated from the rest of the team. And the more isolated you become, the more awkward and difficult it becomes to re-establish communication and cohesion.
Pairing by default prevents that downward spiral of isolation, because the team must always communicate at least enough to decide not to pair on a particular task. And, if deciding not to pair takes a special effort, the easiest thing to do is now the best thing for your team’s health.
Sync early; sync often.
If you have more than two people (one pair) on your team, set aside a few minutes near the start of each day for a quick stand up meeting to sync up with each other. This lets you prepare for the day, reminds everyone to exchange information, and provides an opportunity to reinforce social cohesion with everyone on the team — especially the people you don’t pair with often. A video or audio stand up meeting is the most effective for that purpose, but even a quick discussion in a group chat room will suffice. These meetings can be as formal or informal as your team likes.
In addition to the daily morning stand up, you might find it worthwhile to sync up with specific people after certain events, such as completing a task or feature, or having a call with the customer. This is particularly valuable if it’s something that only one person on the team was involved in, such as a task that the team decided not to pair on. Syncing up afterwards ensures that important information always exists in more than one person’s head.
Write everything down.
Remote teams should make a special effort to document important information about your project, such as:
- The overall architecture and organization of your project.
- Instructions for performing tasks, such as compiling or deploying the software.
- Login information and license keys for project servers, test accounts, tools, etc.
- Important decisions, including what prompted the decision, what alternatives you considered, and the rationale for what you decided.
These are all the sorts of things that every team ought to document, as a matter of healthy project management. But co-located teams can more easily compensate for a failure to do so, because there’s probably always someone within earshot who has the information you need to know. Remote teams don’t have such luxury, especially if you work in different time zones.
Fortunately, if you’re mainly using chat for discussion, a written record is just a Copy & Paste away. If you’re using a persistent chat room with a permanent transcript and good search functionality, it’s done automatically for you. For online whiteboards, save the image or take a screenshot when you’re done, and post it somewhere the whole team can find it. For audio or video meetings, it’s probably not worth saving a full recording (who would want to watch the whole thing?), but you should follow up by posting a written summary of any salient points and action steps.
But, is it worth the effort?
After reading all this, you might have the impression that it’s much harder to maintain a remote team than a co-located team.
In a sense, that’s true. Most people are much more used to working and socializing in a co-located fashion. Their current tools, practices, and attitudes are geared toward that scenario. If you want to have a healthy and effective remote team, you will all need to adapt — establishing new tools, practices, and attitudes. At first, it will be frustrating, sometimes even painful. You and your team will make mistakes. But you will all learn from them and get better.
The most obvious benefit you get in return is flexibility. You can recruit the best people, regardless of where they live. Each team member can work in whatever environment they are most productive in. Team members can move, or work from home, or adjust their schedule, without significantly disrupting the project.
But there’s another, potentially greater, benefit. As I’ve mentioned, most of these tools, practices, and attitudes would benefit even co-located teams. The main difference is that remote teams don’t have as much slack as a co-located team does, so they have to be more diligent and deliberate about these things.
Learning these tools, practices, and attitudes won’t just make you a more effective remote team, it will make you a more effective team, period.
“Conversely, you should never have to provide justification for pairing. Pairing should simply be the default mode of operations.” — I am not hostile to pair programming, but in a consultancy world does this work? How do you justify doubling your billable hours for pair programming? Does pair programming allow you to get more done faster? All the time? Sometimes? How does this affect estimation to clients? In my head, I see 20 hours tasks, having a 40 hour invoice. Does pair programming simply not work in a consultancy? Thanks!
Great questions! Pair programming definitely can work in a consultancy that bills by the person-hour. In fact, Atomic Object itself is an example of exactly that.
Although we don’t necessarily pair on every task (for example, we typically would not pair a straightforward refactoring task), we’ve found that for most tasks, the benefits of pairing are well worth the cost. This is especially apparent when you consider the project as a whole, over the long term, rather than looking at each task in isolation. There are a number of reasons for that:
Pairing helps both programmers stay focused and motivated, so that your hours are more productive.
The code design and architecture you create tends to be better when you have two people working together, bouncing ideas off each other, etc. That better design helps reduce friction and roadblocks on future tasks.
Likewise, pairing helps you avoid mistakes (whether bugs, or just regrettable decisions), or at least notice them earlier, so that you waste less time going back and fixing them.
Pairing ensures that more than one person understands each part of the code, increasing the project’s “bus factor” and greatly reducing project risk.
Pairing encourages knowledge transfer and professional growth, so that each programmer becomes more and more effective over time. Clients benefit from that growth and experience over the course of the project, plus the growth and experience of every previous project each programmer has worked on.
Our customers know from the start that we will be pairing, and we estimate accordingly, so there are no surprises when the invoice comes. Some customers are skeptical at first, but they come around after we explain the benefits, and the fact that we and many other consultancies have been doing it for years, with great success!
I enjoyed your article. thank you much
Comments are closed.