Why communication and camaraderie are necessary for a distributed team
This post was co-written by Harlie Levine
Distributed teams are hard. It’s extremely difficult to have a group of people communicate and work together effectively when you have multiple groups in different places that need to collaborate and create software. Our team took this problem and turned it to 11. We had 20+ people working on a product in three different east coast locations, with a few other people who were entirely geographically isolated (not Antarctica level, but you get the point). While we identified some non-overlapping tracks of work and split the team along those lines, we still had to communicate effectively across the teams pretty frequently. Luckily, our pains are your gains! Here’s a list of some of the pains that we felt as a large, distributed team, and the tools, processes, and general team norms that helped mitigate them and allowed us to move fast and kick ass.
Organizing the team
With up to ten pairs, keeping track of who was pairing with who and where to find them became onerous. To remedy this we created a Trello board. Each person had a card with their picture on it, and each pair was represented by a list on the board. Every morning during standup we were able to drag the cards around until we found a pairing arrangement that worked for the day.
To further ease the pain of daily pair rotation and team distance we created a dedicated Zoom meeting for each pair. This Zoom meeting was indefinite, and we created bit.ly short links for each meeting (i.e. bit.ly/blogtrack_1). The path for the bit.ly short link also lived on the title of the Trello list. So, in the above example, after standup Daria and Bob knew to go directly to bit.ly/blogtrack_1 to join the Zoom meeting and start pairing.
Keeping the lines of communication open
Slack was heavily employed to keep communication open among the team. We made a point of using Slack channels over private messages to ask questions of each other so that answers were shared more widely and more easily discovered when they came up again. Tools like Slack polls made group decision making simple.
Having dedicated and easily discoverable Zoom meetings also facilitated real-time communication. If a face-to-face conversation was the most effective method of communication, all that someone needed to do was pop into a pair’s Zoom meeting (which could be found in the pair rotation Trello board). For that reason, we also kept Zoom meetings open even when co-located with your pair. This way, even if a remote teammate needed to talk to you about something, they could still drop in on the co-located pair almost as if they were co-located themselves.
Even though we were part of a larger distributed team, local communication was still important. To make sure we could hear one another when co-located, we made sure the headphones we used were open-backed. Treating everyone as remote didn’t stop us from having local conversations, but it made us more cognizant of our remote teammates. Open-back headphones allowed us to overhear conversations and interact with our co-located teammates, but if a conversation was more than just a second or two then it was off to a Zoom meeting so that our remote pairs could still be a part of that conversation.
When we began the project, team meetings on Zoom often meant that the team in New York would gather in a room and join the meeting, while team members located elsewhere would join individually or in smaller clusters. After some time we realized this was causing reduced participation and exclusion of those not in the larger room. Switching to a system in which everyone joined individually increased engagement across the board.
With such a large group we also found that meeting moderation was necessary. People frequently talked over and interrupted each other. We moved to a system where people raised hands when they wanted to speak, and it worked surprisingly well. The meeting facilitator would be responsible for keeping track of who should be talking next, though often fellow teammates would organically share that responsibility. In the event the facilitator of the meeting was also sharing their screen, they would join the Zoom meeting on a second computer so that they could have one screen for sharing and one for viewing Zoom participants in the gallery view.
As with the pairs, having a dedicated Zoom meeting for the team with a bit.ly shortcode made finding the meeting easy. Additional tools that further eased the pain of distribution were digital whiteboards like RealtimeBoard, and lists on our Trello board. The digital collaboration spaces gave everyone the same level of access to contributing to the conversation, which meant people felt more agency to share.
Remote screen control
Since we spent most of our day pairing, having the right tool for sharing screens and control was critical. Unfortunately, there is no silver bullet to this problem. Having multiple options and a willingness to experiment was critical to minimizing the pain that comes with pairing remotely. Some days Zoom screen sharing with remote control worked better than the built-in MacOS vnc tooling. Other times that was reversed. Sometimes a pair even had one machine for screen-sharing and coding, and another for the Zoom meeting. Experimenting and doing what worked best on a given day heavily reduced the pains felt from virtual pairing.
As with most things in life, distributed teams work better when they’re rooted in friendship.
It’s easy to forget that those people sitting hundreds of miles away writing the code that caused your merge conflict are on your side. They’re your teammates. But more importantly, they’re your friends. By viewing your distributed compatriots through the lens of friendship, it helps create an empathetic attitude across the team. Small acts like in-person bonding time when remote teammates are in town, and photos of everyone on the Trello board remind you that you’re all in this together. It helps eliminate an ‘us-versus-them’ mentality, and it helps keep teammates mindful of everyone else’s pains that come from having a heavily distributed, large team.
Currently we are seeing the following error message appear daily in the even log of one of our eRoom application servers:
Event Type: Error
Event Source: eRoom
Event Category: eRoom Diagnostics
Event ID: 148
Computer: (Server Name)
A deadlocked thread was detected in process inetinfo.exe.
I previously saw a thread containing the same error message from one of the eRoom forums where it was advised to run an IIS reset, I have tried this across all 5 application servers however it hasn’t resolved the issue. We run eChecker quarterly so this also hasn’t fixed the problem. I have noticed that the process w3wp.exe consumes a high amount of memory which is also an iis process. I thought recycling the application pool may resolve the issue however I believe an IIS reset would just do the same thing. Is there anything else that can be done to resolve this error ? Could killing the inet.info process then running an iis reset to restart the process resolve the error ?
When clicking on “View conversation” button in a Yammer notification via Secure Mail there is different behavior when the Yammer app is installed or not installed.
Scenario #1: When the Yammer mobile application is installed and the “View conversation” button is clicked in a Yammer notification via Secure Mail, nothing happens and a small pop-up window informs the user to install Secure Web. Uninstalling the Yammer app will allow the Yammer message to display in Secure Web.
Scenario #2: When the Yammer mobile application has not been installed and the “View conversation” button is clicked in the email notification via Secure Mail, the user receives a Google Play Popup message prompted to download the Yammer application for Android. When the user clicks “No thanks,” they’re taken back to Yammer homepage.
The expected behavior is the following, when the Yammer app is installed, if you click on any Yammer link within Secure Mail, it should go to the Yammer app.
This document (7022646) is provided subject to the disclaimer at the end of this document.
Micro Focus Filr 3.3
Filr supports the use of WebDAV tools and enables you to access your Filr files through WebDAV as documented in the Filr User Guide. However, after applying the Filr 3.3 Update, access to Filr folders and files through WebDAV no longer works. This includes, but not limited to:
Mapping a drive to Filr folder in Windows
Mobile apps such as PDFExpert, Bluebeam, etc.
An updated fix for this issue is available in the Filr 3.3.3 Update. The original fix which was part of Filr 3.3.1 Update did not resolve the mapping of mapped drives to Filr folders.
Using the Windows Web Client (WebDAV) to map a drive to Filr requires a signed SSL certificate. Using the default self-signed certificate will prevent the mapping of the drive.
If you experience that uploading of files greater than 3MB is not possible when using a mapped network drive to Filr from Windows, please consult TID 7022711.
This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.
This seems to be an issue related to the Windows Web Client when the WebDAV authentication method used is Digest. If the WebDAV authentication method is changed to Basic, then this problem is resolved and users are able to upload files greater than 3 MB using the Windows Web Client.
Here are some possible solutions to this problem:
Use a 3rd party WebDAV client such as BitKinex.
Modify the default Filr WebDAV Authentication method from Digest to Basic authentication. This can be done from the Filr appliance’s 9443 interface under the WebDAV Authentication menu (as documented in the Filr Administration Guide).
IMPORTANT: When using Option #2, please ensure that your Filr site does NOT allow non-SSL access. Basic authentication which passes user credentials in clear-text should only be considered as an option when using SSL (https) to connect to the Filr site. Also, after re-configuring Filr to use Basic authentication, users will need to add the mapped folder to Filr again.