In part 1, we discussed the various tools the distributed mobile web engineering team at the Wikimedia Foundation uses to stay synchronized. While the tools are critical to our success, it takes a lot more to ensure that we can successfully work together despite the geographic distances between us. Our development procedures and team norms are the glue that holds it all together.
As with the tools we discussed previously, the practices and norms I’ll discuss below are by no means unique to—or only useful for—distributed teams.
Rituals
When you can’t just walk across the office or poke your head over the cubicle wall to sync up with a teammate, regular, structured moments for real-time, intra-team communication become critical. The mobile web team is a scrum-inspired agile team. As such, we use regular stand-ups, planning meetings, showcases and retrospectives to have some real-time, focused conversation with one another. Because we hold these meetings at a regular cadence and consider them critical touch points for the entire team, we think of them as rituals rather than regular meetings.
The stand-ups in particular are excellent for synchronization. Unlike traditional Scrum, we do not hold stand-up meetings every single day; rather, we do ours on Monday, Wednesday and Friday. We use this time to let everyone know what we’ve been working on, make commitments about what we will be working on, alert the team if there’s anything blocking us from getting our work done and quickly triage any bugs that have been reported since we last met. While we can always look in Mingle (our project management tool, see part 1) to see who is working on what and when, these brief meetings make it easier to raise issues and communicate about where further collaboration between teammates may be valuable.
Often, conversations about blockers and problem areas start during the stand-up and continue between the interested parties after the meeting has concluded. The meeting is kept short, time-boxed at 15 minutes, so there is little overhead; the meeting stays focused and we communicate just enough to keep us all moving forward.
The other rituals provide a great way for us to stay in the loop, bond with one another and allow the team tremendous influence over the product and our process. While their primary purposes are not about day-to-day synchronization like the stand ups, the other rituals are essential for reinforcing our self-organizing team. Particularly since we are distributed, these rituals are sacred, as they are the primary moments when we all know we can work together in real time.
Ensuring that our rituals happen consistently and regularly makes it easy to plan around them and maximizes the likelihood that everyone will be in attendance. This is pretty easy for us to achieve because we maintain a regular and predictable development cycle. We work in two-week cycles, or iterations. While we code during an iteration, we also simultaneously plan for the next one. Maintaining a regular rhythm to our development cycle helps us all feel on the same page, promoting a deeper sense of unity on the team.
Finally, there are also some guiding principles that we follow for all of our scheduled meetings and rituals:
- Every meeting must support remote participants.
- All Google Calendar invites should include a link to a Google Hangout.
- Meetings always start on time, plus or minus a few minutes.
- Meetings always end on time, unless we come to a consensus as a group that the meeting should go longer than planned
These principles help make the lives of all team members, particularly those working from remote locations, much easier. Ensuring support for all team members, we can focus on the real purpose of the meeting without wasting time on mechanics. Focusing on punctuality, we prevent burnout from the seemingly-endless death march of meetings that regularly start late and go over time.
Team norms
The mobile web team norms are a handful of conventions to make life on the distributed team easier. These are guidelines that we have agreed to via consensus and have publicly documented, so we can easily refer back to them whenever necessary.
Some of the most important norms:
- If it didn’t happen on the mailing list, then it never really happened.
We cribbed this norm from the Apache Community code of conduct and discussed it a bit in part 1. Requiring that decisions be announced and discussed on our mailing list ensures that everyone is privy to them, and that they are automatically archived for future reference.
- Be careful about taking things too personally or reading too deeply into someone’s comments.
This is particularly important because much of our communication happens asynchronously through text-based media. With text-only communication, you miss out on non-verbal cues that you would otherwise get when talking with someone face-to-face. These verbal cues can drastically impact the meaning of what someone is saying. For instance, the way someone smiles or raises their eyebrows when saying something may make it obvious that they are joking or being sarcastic. But in text-only communication, it’s incredibly easy to completely miss or misinterpret things like humor and sarcasm.
Besides missing out on non-verbal cues with asynchronous communication like email or comments in code review, you miss out on the opportunity to instantly ask someone for clarification or to challenge their assumptions. Sometimes, getting clarification on something via email may take days, even when people reply promptly! As a result, it’s important that we all remember to always take what we say to another with a grain of salt, and be sure to give one another the benefit of the doubt. Also, there are people on our team who are not native English speakers. In our case, everyone is fluent in English, but it is still easy to miss some of the nuances and idioms in English or English translations.
Approaching communication this way helps enhance a feeling of trust amongst the team, which has the effect of ultimately strengthening our bonds. The stronger we are as a team, the more effective we can be.
- The ‘Rule of 3’
For us, the ‘Rule of 3’ means that the three primary disciplines of our cross-functional team (engineering, design, product) must be involved in any decision making. In practice this means that there should be a representative from each discipline at any meeting, regular or ad-hoc. This has the benefit of ensuring that all viewpoints are represented, and more importantly it increases the likelihood that the nuances of the meeting and any decisions that came out of it are accurately reflected back to all actors from each of the disciplines. This nicely complements our norm “if it didn’t happen on the mailing list, then it never really happened.”
Face-to-face from time to time
You never quite appreciate how awesome it is to be in the same room as your teammates until you are sitting on opposite sides of the world for a while. We strive to get the entire team together at least twice a year. This gives us an opportunity for extra high-throughput meetings, particularly useful for doing strategic planning, as well as for creating opportunities to bond. While we certainly work hard when we’re all together, we also try to take use this time to get to know one another better outside of work. This helps us build better empathic relationships with each other, which in turn facilitates even better communication with one another when we’re not in the same room. We also try to structure time for team outings. Our team recently went to jump on trampolines and play trampoline dodgeball together. It may seem superfluous and silly, but moments like these really help us strengthen and deepen our relationships as a team, which translates to greater efficacy as a team, which then translates to higher-quality outputs.
Conclusion
Ultimately, it comes down to the team and its ability to stay disciplined to find success. Much, if not all, of what we discussed above may feel relatively simple and intuitive. This is a good thing! Keeping best practices lightweight, well-documented and consistent is crucial for their successful adoption. Approaching our best practices with this perspective, we have been able to remain disciplined and find success without becoming bogged down by our own process.
One of the most rewarding things about working on a distributed team is that, in order for the team to function at all, we must really learn how to communicate well. It is not by coincidence that much of what we discussed above and in part 1 focuses on facilitating and protecting our ability to do just that. On a collocated team, it can be easier to skate by with poor communication practices and have resulting problems hidden by positive-feeling, interpersonal face-to-face interactions. Being forced to learn how to communicate well from the very beginning has really helped our team grow and be successful. My experiences on various engineering teams—particularly with the mobile web engineering team—has taught me that quality communication is the cornerstone of a healthy and productive team regardless of whether it is distributed or collocated.
Arthur Richards
Sr. Software Engineer, Mobile Web team, Wikimedia Foundation
Can you help us translate this article?
In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?
Start translation