Hans Samios' Personal Lean-Agile Knowledge Base

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== How Can We Work More Effectively with Remote People? ======

... and benefits of thinking that we have remote people on our teams, even when we don't have them.

When we first started Scrum we talked in general about how to work with people who were remote. The conversation was based on the idea that co-location is ideal because it allows for high bandwidth communication, and that as we work with remote people we need to be working our communication approach so that it is as close to what you can achieve with co-location as possible.

At the [[https://www.scrumalliance.org/courses-events/events/global-gatherings/2015/phoenix-2015|2015 Scrum Gathering]], there was a presentation by Arthur Richards (@awjrichars) on [[https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/Global%20Scrum%20Gatherings/2015%20Phoenix/Presentation/RichardsArthur_developing_distributedly-gsgphx-2015.pdf|"Distributed Agile"]] which brought me new insight on how to effectively engage people who are working remotely. In addition, the approaches he talked about would also help non-remote teams work well together.

Arthur works with Wikimedia, an organization that relies a lot on remote folks, but he says that he really didn't understand how bad it was to be remote, how big an issue it was, or how to go about addressing it until he became remote after being co-located for a long time. His revelation was that the reason he was able to be engaged when he was co-located was that, any time he had a problem or issue or didn't know what to work next, he simply spoke with another on the team or his management and immediately resolved the issue. He found that when he was remote, this recourse was not available with the result being that he would often not know what was going on, would often not be able to understand what was required next (and so did something he thought was right) and couldn't quickly get answers to even the simplest questions. And it got worse as time went on - the "core" co-located group disengaged even more when they saw Arthur doing things that were not relevant to the work at hand or, even worse, doing things that didn't seem to have anything to do with the overall project.

In some ways, the problem Arthur had was caused by the fact that the co-located group had some pretty sloppy practices from the perspective of engaging and communicating with the whole team. The problem was the only people who felt the problem were the remote people, and they really didn't have the presence or language to drive the team to a discussion about how this would be improved.

And here was the realization for me - **co-location can hide undisciplined team practices!**

Now the good news was that Arthur was the Scrum Master, so he raised the issue with the team and started to coach the team to crisper practices aimed at helping them be more of a team, engaged in a common goal, embracing the team members who happened to be remote. There were a lot of lessons they learned, but the biggest ones were related to a set of team agreements and approaches they evolved to, aimed at making sure everyone was on an equal footing. Some of these ideas that Arthur's team developed were:

  * For all team decisions "If it doesn't get documented on the team mailing list, then it didn’t happen." The idea is to reduce the number of times a decision is made at the coffee room, for example, that the whole team does not see.
  * Establish a "single source of truth" (eg wiki, Jira, source code control), make sure everyone know when to use each source and that when the team member leaves for the day, the information in those sources are up to date.
  * Make sure that everyone reads the team stream first thing after coming to work so they can see what other people have done while they are away.
  * To reduce arguments, establish a team rule that everyone should assume that the other team member acted in good faith (i.e. didn't intentionally do something to annoy you).
  * Establish a rule that if you cannot assume good faith for something that you see then you have to get onto a video chat with the relevant person and try to resolve it "face-to-face".
  * Use video chat and set things up so that everyone uses camera / microphones on their computers (no wall mounted cameras). That way everyone interacts the same way with each other.
  * Establish a "rule of 3" decision process. The team was finding that decisions were sometimes made by people on the team from one discipline (e.g. development) that impact others in a bad way. The team had three disciplines on it and so the rule of 3 was that or any decision made, all three had to be involved.
  * For the relatively few times a team does get together face-to-face, a lot of the time was used to have fun (as opposed to work) as that helps with social cohesion. This helps the team perform better when they are all remote again.

The results were dramatic for remote team members but there were also results for team members that were co-located. By having this approach in place the team had:

  * A greater sense of resilience. The feeling now is that it doesn't matter where team members are, what disaster has happened, the team will be in a good position to work it. Product Owner traveling - no problem. Scrum Master out dealing with a sick kid - done. The fact is that there are many situations where we any of us could be "remote" even on a co-located team. It therefore makes sense to set up team practices that allow you to deal with the situation.
  * It helps with team engagement in that, in reality, even the co-located folks didn't always have all the information. They just had an easier way of dealing with it when they recognized the problem. By making the practices common, it actually helped everyone.
  * It provides an increased sense of freedom. You knew that because of these practices you could support the goals of the team without having to be there physically.
  * Leveraging timezones meant they are closer to a "follow the sun" operation while still able to keep everyone informed and engaged which really helped when dealing with defects.

In addition, and specifically for the Wikimedia team, since they now know they can work effectively remotely, the approach meant they had:

  * An increased hiring pool – not just San Fransisco.
  * Increased potential for cultural diversity (important for global product like Wikipedia)

This is just the set of practices Arthur's team settled (and reported) on. There are a number of other ideas out there. For those interested in learning more see [[https://oduinn.com/|John O'Duinn's Blog on working remotely]] with tips and tricks related to house-keeping, meeting logistics and meeting moderation.

My view is that this kind of thinking is useful not only for teams that have remote people, but also in general to help with overall team engagement. I'd be interested in hearing from your experiences.

{{tag>BlogEntry FAQ team remote distributed collaboration improvement}}