TL; DR: Remote Agile Anti-Patterns — Pitfalls Successful Distributed Teams Avoid
We started this series on remote agile with looking into practices and tools, followed by delving into virtual Liberating Structures, and how to master Zoom. This fourth article now addresses basic remote agile anti-patterns — the pitfalls any distributed team wants to avoid to become successful.
Update 2020-04-20: I created the Remote Agile Guide — a handy PDF of all articles of the remote agile series. Download your copy of the Remote Agile Guide here.
Do you want to get this article in your inbox? You can sign up here and join 26k other subscribers.
Culture
- What about our culture? The organization is not doubling down on transferring or preserving its culture in a remote agile environment. (My favorite definition of company culture goes as follows: Culture is what happens when you are not looking. Now apply this model to a situation where there are no watercoolers and coffee machines that can act as waterholes for the tribe, and where having lunch is not an option. Going remote requires more effort to cultivate your organization’s cultures, particularly at the leadership level.)
- Remote Agile is just standard work-life plus Zoom: Pretending that working remotely is the same as usual except for the video cameras. (This approach ignores all the challenges that distributed team face, for example, not investing enough in getting to know each other better to build trust. We are Social animals and need to meet In person sooner or later to build lasting trust among teammates, thus creating psychological safety. Moreover, there are difficulties in reading the virtual room in general, which means that taking decisions to the team or calling out introverts manifest themselves differently in a remote working setup. Trust is the beginning of all; without it, transparency, inspection, and adaptation would be able to work their magic, and we end up as distributed feature factories.)
Remote Agile Anti-Patterns: Collaboration
Ignoring the etiquette and good practices of remote work:
- Neither fish nor meat: Hybrid events create two classes of teammates — remote and co-located — where the co-located folks are calling the shots. (Beware of the distance bias—when out of sight means out of mind—thus avoiding the creation of a privileged subclass of teammates: “Distance biases have become all too common in today’s globalized world. They emerge in meetings when folks in the room fail to gather input from their remote colleagues, who may be dialing in on a conference line.” (Source.) To avoid this scenario, make sure that once a single participant joins remotely, all other participants “dial in,” too, to level the playing field.
- Too many meetings: Every communication feels like a (formal) meeting. (This is often resulting from a trust issue at the management level or the felt need to come to unanimous decisions across the team. Instead, put trust in people, uphold the prime directive, and be surprised what capable, self-organizing people can achieve once you get out of their way.)
- Surveillance: Trust won’t be built by surveilling and micro-managing team members. Therefore, don’t go rogue; the prime directive rules more than ever in a remote agile setup. Trust in people and do not spy on them— no matter how tempting it might be. (Read more about the damaging effect of a downward spiraling trust dynamic from Esther Derby.) https://www.estherderby.com/the-future-may-be-remote-must-it-include-surveillance/
- Mindless rituals: Leadership belief and or facilitation practices turn once useful routines into mindless rituals. (For example, think of Groundhog Day-style retrospectives over and over again. Answering the same three questions every single time is the easiest path to kill any form of creativity and collaboration. While this is hard to avoid in face-to-face environments, it requires much more dedication and energy in a remote agile setting.)
- Death by PowerPoint: Meetings still revolve around an individual broadcasting a slide deck. (While you might get away with this approach for some time in face-2-face environments, it will not fly with distributed teams. Sessions need to inclusive, interactive, and engaging to entice collaboration, think Liberating Structures, and Training from the Back of the Room.)
- Delaying important work: Saving the ‘hard work’ for later to be done in person. (This delay tactic is merely increasing lead time and cycle time by creating new queues. The right time for handling important work is right here, right now.)
- A misconception of time: Applying the understanding of time from face-to-face environments to remote collaboration and interactions. Typical symptoms of this fallacy are:
- Remote sessions are too long and exceed the recommended 2-4 hours.
- Remote sessions do not provide enough breaks, for example, 10 minutes per hour.
- The timeboxes are too short for remote collaboration and create stress rather than a focus.
- The facilitators do not enforce timeboxes, and discussions are meandering aimlessly.
- Management insists on a 9-to-5 schedule although asynchronous communication does not require this mental model from the factory era. Instead, agree on blocks of time that are overlapping for everyone when virtual events can take place.
Communication
- Unstructured communication: “Didn’t you get the memo?” (There is no clear practice on how to communicate which kind of information to whom. Are we talking about email, Slack, the team wiki, a comment in Github, or the biweekly remote brow bag session? This lack of structure and agreement leads to stress—how can I avoid missing important news now that there is no longer a watercooler; do I have to monitor all Slack channels in real-time—and probably a feeling of being excluded. Maybe, this effect is just a missing update to the working agreement or team charter. But what if it is done deliberately? (Honi soit qui mal y pense.) in a remote agile environment always requires to overcommunicate and be completely transparent.)
- Instant replies: The organization expects that all communication needs to be synchronous. (There is undoubtedly a need to be available for synchronous communication over the day; think of remote Daily Scrums or virtual watercooler meeting. However, expecting that all communication is immediate causes too much disruption for focused, deep work. The practice of ‘do not disturb hours’ also applies to distributed teams.)
- Complexification: The wrong tools or too many tools are used in the belief that technology will fix all collaboration issues:
- Ask yourself: What is the marginal utility of an additional tool? (The law of diminishing returns applies to your toolbox, too.)
- Therefore, keep it simple. (Soft factors such as trust at the team level drive successful collaboration; it is not a faster VPN connection.)
- Are you using the right toolset? (If your team members do not have access to the right tools, making remote agile collaboration successful is challenging, if not impossible. (If your organization still insists on using Skype for Business as the primary collaboration tool, they might be in for a surprise. Working in a distributed team is demanding enough; trying to do so with inferior tools is adding an unnecessary layer of complexity.)
- Tech is your problem: The organization does not provide support with technology or connectivity in the home-office. (Typical manifestations are the lack of a budget for audio or video hardware or accessories such as green screens or proper lighting at the home-office. Or, the necessary software is not licensed, and the organization does not pay for the Internet connection. All of these symptoms fall into the category of penny-wise and pound-foolish.)
- No training: The organization is not actively training team members in the technology, software, and practices that the distributed team relies on. (Don’t assume that people know how to use the technology and software involved. Instead, offer regular training classes to signal that not knowing how remote agile collaboration works can be resolved. Additionally, at the facilitator level, check-in with novel participants of important remote events beforehand to make sure that their setup is working to reduce their stress levels during the meeting—stressed people are rarely top collaborators.)
- A lack of Netiquette: The team ignores the first principles of remote communication: no interrupting, mute yourself when not talking, use a clean, humane, and kind language in messages. (This ought to be a no-brainer, given its principles have been around for decades. Nevertheless, a weak facilitator can easily wreck a team’s potential if those remote agile anti-patterns go unanswered. By the way, Matt Mullenweg has an interesting opinion on muting: “One heterodox recommendation I have for audio and video calls when you’re working in a distributed fashion is not to mute, if you can help it. When you’re speaking to a muted room, it’s eerie and unnatural — you feel alone even if you can see other people’s faces. You lose all of those spontaneous reactions that keep a conversation flowing. If you ask someone a question, or they want to jump in, they have to wait to unmute. I also don’t love the “unmute to raise your hand” behavior, as it lends itself to meetings where people are just waiting their turn to speak instead of truly listening. So what should you do? Use the latest and greatest hardware and software to have the best of both worlds, a fantastic auditory experience for you and your interlocutors and little to no background noise. […] Save mute for coughs and sips of drinks.” (Source.))
Remote Agile Anti-Patterns: Facilitation:
- 5 minutes before 12: The host joins a remote event only a few minutes before the start. (My suggestion: Be the first one in the meeting about 10-15 minutes early. You may have to handle the waiting room, plus other participants may have technical issues. Also, prepare a time-line of the remote agile event with a script so that you have canned questions, instructions, and other texts at hand without breaking into a sweat. You will need your energy for other tasks. Facilitating remote agile events requires more preparatory work, more documentation, and more debriefing. As a facilitator, you will spend more time at your desk creating documents.)
- Lone maverick: Facilitating events with more than 30 people without a co-facilitator. (Depending on the task, its context, and the experience of the participants, there will be a maximum number of attendees to a remote agile event that a single facilitator can accommodate. Beyond that threshold, hire a co-facilitator for the event.)
- Mr./Mrs. Speaker: Becoming too domineering as a facilitator. (While it is true that a host of a remote agile event needs to direct the event more intentionally by comparison to the face-to-face version, he or she shall not slip into a “Speaker” role, having the final say in each matter.)
- Everyone knows Liberating Structures: No, they do not. Therefore, do not assume that participants in remote events are familiar with Liberating Structures. (While some are so simple that they can be picked up along the way, others require preparation and probably even a training session in advance. For example, think of Critical Uncertainties or Ecocylce Planning.)
- Everyone did the homework: Anticipating that everyone is well prepared for the event is a fallacy. (Principally, this is not different from real-world experience. No matter how attentive and organized you are, your participants probably won’t read your instructions on how to prepare for the event. However, in the remote realm, we face a compound effect as we use additional technology to host the event as well as potentially unfamiliar practices such as Liberating Structures to entice collaboration during the event. Be prepared to deal with these situations.)
- Using flipcharts: Using real whiteboards or flipcharts in a remote event—captured by a video camera—and expecting everyone to understand what has been written or sketched. (This is a useless exercise as remote events in corporate settings normally do not take place in a studio with appropriate lighting and 4K cameras. Instead, consider using digital whiteboards or drawing apps like Paper on an iPad to ensure the inclusion of everyone.)
- Not having a plan B: How do you continue working, if Zoom, Teams, or Webex fail? (The host of a remote agile event should plan for the inevitable: Internet access is down, the firewall is acting up, the video conferencing system is no longer working. There should be a contingency plan, providing alternative tools to the team. Moreover, this plan B should be tested beforehand. It is a bit like restoring a backup file: if you never test this as an exercise, do not expect it to work in the case of an emergency.)
Conclusions
Working as a distributed agile team is not merely the continuation of usual practices with a video conferencing tool but practically a paradigm shift, emphasizing self-organization, trust, transparency, and the inclusion of everyone. While this may look obvious on paper, realizing the required changes at a team or organizational level is a massive undertaking that many might oppose. Hence you encounter numerous remote agile anti-patterns in practically all organizations that did not start as a distributed organization from the beginning.
What remote agile anti-patterns have you observed? Please share it with us in the comments.
✋ Do Not Miss Out and learn more about remote agile anti-patterns: Join the 7,300-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
Remote Agile Anti-Patterns: Related Posts
Remote Agile (Part 1): Practices & Tools for Scrum Masters & Agile Coaches.
Remote Agile (Part 2): Virtual Liberating Structures.
Remote Agile (Part 3): Mastering Zoom.
Download the Scrum Anti-Patterns Guide: 160-plus ways to improve your way of Scrum.