Agile established conversations as one key principle. The set up in those companies that follow agile methodologies are designed to maximise the interaction among developers and other people involved in product or service development. When working in distributed environments, the need to have those conversations does not change, but since the environment is significantly different, the required set up must be too which affects to processes and practices. An immediate question comes to mind…

Should we do stand-ups?

My recommendation is to not have stand-ups. Instead, substitute them for a different type of meeting, with slightly different goals.

The new meeting

The name

Let me start by the name. I like to avoid calling these meetings stand-ups to minimise the association with what most agile methodologies propose. Different goals, different set up, different dynamics… different name.

These new meetings I have run in the past have been heavily determined by the availability of the participants (time zones, productivity peaks of each participant, breakfast habits depending on participants culture, etc), the set up (distributed or remote, for instance), the company culture, the nature of the team (with fixed or variable/flexible composition, with the participation or not of stakeholders, etc), the room I have as manager to propose these kind of actions, etc. I have used several different names like sync-up, fast-track… meeting.

I really do not care about how to call it as long as we do not use the word “stand-up” to avoid a direct association to those.

Mandatory?

Nowadays it is common among distributed or remote teams that most developers agree on having short, daily meetings but there used to be a time in which I faced strong opposition. Back then and today, I tend to avoid making them mandatory. I promote them by example instead. In my experience, this is one of those topics where peer pressure works better than top-down or a general policy approach, specially when senior developers reluctant to participate are involved.

The video chat tool

There used to be a time in which finding solutions that worked on Linux was the main challenge, so a general excuse to push back on these kind of meetings. Phones/Android has come to my rescue many times in the past. Hangouts were my preferred option for a long time. Although now there is a wide variety of options that works on Linux, in combination with the Google Calendar, Hangouts (now Meet) is still my favourite.

As manager, I have faced several obstacles with the video chat set up that I have had to overcome.

• Technical limitations: I named the lack of solutions for Linux during a long time. Another challenges has their origin in the limitations employees face on the applications they can install on their machines. This is becoming less of a problem nowadays since more and more companies are understanding how important it is to provide at least one on-desk video chat solution. When working in environments where people from different organizations participate like consortiums, you end up with several video-chat solutions installed. Configure each one of them so they do not collide can become a challenge. Again, Android has come to the rescue a few times in such situations for me.
• Legal considerations: legal restrictions have to be considered in every case. Using freemium services, for instance, or free accounts of commercial video conferencing service providers for internal topics is unacceptable in my opinion. Convenience has limitations. Having managed corporate teams that work in the open for some years now have made me familiar with this issue early-on. An “open by default” policy helps to overcome many of these challenges but any team needs a channel that meets corporate standards when discussing through video chat internal topics, no matter if you are working in an Open Source project, a standard company or a consortium.
• Business considerations: GitHub has been recently bought by Microsoft. For those who compete with Microsoft in a specific market or are providers of those companies who do, the purchase might bring challenges. The same concept applies to the use of video-chat tools. Google Hangout or Skype, for instance, might be great but not compatible with the activity your company develop for a variety of reasons. This factor needs to be considered when choosing a video-chat tool.
• Religions: we all have prejudices/biases. Very frequently engineers install in their machines all kind of programs downloaded from a variety of sources to do their job, but they refuse to install a plug-in from a specific vendor to use a specific video conferencing option. Most sales people I have worked with are devoted members of the “Apple Religion“. Many designers are so used to paying for their tools that they become suspicious when offered something open with little or no cost. I am a Firefox user, I dislike solutions that requires a specific browser. As irrational that these and similar examples might sound when it comes to choosing a video chat tool, I tend to put effort in satisfying team members biases as long as no freemium services for company meetings are used and there is an available option for Linux users.

I am currently using the following tools on regular basis:

• appear.in for BuildStream project (paid account).
• Hangout/Meet since Codethink, the company I work with, uses some of the Google services.
• Zoom for Linux Foundation stuff, since I represent Codethink in that consortium.
• Skype for conference calls or regular phone calls.
• Onconference for some meetings at Codethink.
  • People who work on the road, specially sales people, tend to prefer the phone over video. For these cases, where some people join through phone and some through video chat, there are solutions out there that work very well so you do not need to choose between one or the other way to connect. You have both.

The main goal is to have productive meetings where everybody joins because they feel that are important, without you as manager having to worry about legal issues. In general, I think that the tool should not get in your way as manager. Nowadays there are plenty of good enough options. Try several options before sticking with one and be ready to change it and have more than one.

Where?

One of the ideas I like about agile is the co-location concept when it comes to the office set up. The best way to translate some of the benefits that such agile practice offer into distributed and remote environments (DRE) is to join the meetings from your desk. It reduces the preparation time and the overhead associated to meeting rooms reservations.

Even if part of the team is at the same office, my recommendation is that everybody live the same experience during a meeting. Use your laptop or PC and get a headset. Mute yourself when you are not speaking, raise the gain of your mic so you can whisper and be perfectly heard, which helps to not disturb those colleagues around you, and enjoy the ride.

When working from home, I recommend to use headsets too, so people hear you with no echo, your dog does not become a participant, etc. I do not always follow this last advice because my current set up at home is a good one. I should anyway.

Meeting goals and dynamics

Duration, start and finish

Due to the nature of the channel used, short, daily meetings will need to be slightly more structured than stand-ups which normally increases their duration. Try not to pass the 15 minutes mark including the “connection time”. It seems hard at the beginning but it is perfectly doable.

Due to the lack of face to face interactions on regular basis, short, daily meetings become essential for those working on DRE. While people connect, it is a good time to chitchat with your colleagues. Providing those initial 2-3 minutes before starting is frequently (not always) a good thing. Somebody got a haircut, the weather at somebody’s place is particularly sunny, a team member has a new banner at his office, it is Monday morning and one participant joins after her vacation… these are quality moments for any distributed/remote team. Honour them.

If the video-chat room closes when the chairman leaves, make sure the chairman keep it open a couple of minutes after the meeting is over. Again, chitchatting in this context is a good thing.

Stop reporting!

If you can only afford one takeaway from this post, take this one: in distributed and remote environments, meetings are not for reporting. Report offline, preferably in advance.

Meetings are expensive, hard to manage and exhausting. But in DRE, they are more expensive, significantly harder to manage and even more exhausting. I will talk about this more extensively in another post related with team meetings and 1:1 but, for now, I would like to say that because of these arguments, you should maximise the time for topics involving short discussions, brainstorming, dependencies discovery, opinions, etc.

So I recommend to remove the concept of “what I did yesterday and what I will do today”. Keep reports on the diary (I will talk about the diary in another post), promote a habit of reading the diary in advance and focus the meeting on topics leading to participation. And if you do not like the diary concept, use dashboard to visualise the WIP, described on tickets, make engineers report about their activity through mail on regular basis, etc. Whatever it fits your need except using meetings to report or communicate information that can be sent offline in advance.

Good practices

I like people to take these meetings seriously because they are really important in the long run. Sometimes I come across people that attend to these meetings while having a walk and smoking or they turn off the camera while doing something else. It is a consequence of the old school “conference phone call” culture.

I perfectly understand that attention does not necessarily depend on being in front of the computer and that a relaxed atmosphere is frequently a plus in some meetings, but I discourage these behaviours on this kind of meetings. I tend to be more flexible with “ad-hoc” 1:1 meetings.

No matter how informal these fast-track meetings are for you, think about those colleagues at the office who cannot do what you are doing, or the impact that generalising your practices might have on the team or the project.

In video chats, unlike f2f, somebody always need to be in control because you cannot afford having two people talking at the same time, due to technical limitations, for instance. Some formality is always required. Here are some tips to consider:

• Create a routine that helps you to avoid moderation like:
  • Using a pre-determined sequence for providing turns. There are tools in which participants are ordered based on when they join, or their user ID, etc. Use those features in your benefit to reduce the need for moderation.
  • Favour those who join on time over those who arrive late somehow.
  • Make sure people join “on mute”.
• Create key words for highlighting technical issues like somebody’s mic is not working or the connection “is choppy”.
• Do not take notes by default but make sure people keep track of the action points or further conversations that needs to happen.
• If something comes out of the meeting that requires in depth discussion, schedule a specific meeting. Make a note, say it out loud and move on. Keep “the flow”.
• Make use of any possibility provided by the video chat tool to add labels or tags to your screen, like a state and emoji…everything that provides context or information about your state helps.
• Provide the link to the video chat room in the calendar event.
• Add 1 and 5 minutes notice notifications for these events. Those integrated with your desktop notification system are way more efficient than the mail ones for daily events.

Summary

I believe that DRE teams benefit from having a short, daily meeting focused on participation over reporting, where there is some room for chitchatting, using a tool that everybody feel comfortable with, that also meets corporate policies and, when working in the open, Open Source community standards. The experience for every participant should be the same so I recommend having those meetings at your desk.

As soon as there is one distributed or remote person in the team, you are working on a DRE. Adapt the short daily meetings to that reality.

Other articles of this series

• 0. Introduction: introductory article where I explain the motivations to write this series of article and my goals.