… 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 2015 Scrum Gathering, there was a presentation by Arthur Richards (@awjrichars) on "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:
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:
In addition, and specifically for the Wikimedia team, since they now know they can work effectively remotely, the approach meant they had:
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 John O'Duinn's "We Are All Remotes" 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.
Note: This posting was originally published at Working with Remoties ...