I work on a distributed team. The testers are spread across two offices (one in Canada and one in the UK) and the developers are spread across 6 offices in Canada, the UK, Germany and the US. As you might imagine, this leads to some difficulties with product development. Communication is one of the things that is difficult both due to the logistics of different time zones and locations, as well as the tendency to revert to poor methods of communication (like email). We have communication tools like Google Hangouts and other video conferencing and screen sharing services that can be really helpful, but there is still a barrier to communication in those mediums that is not seen in face to face communication.
But this is the team I’m on. There are obviously challenges that come from being a distributed team, so what are the ways we can overcome them, and perhaps even leverage them to use their power? One of the things I have heard said, and seen confirmed in my observations of various team and products, is that your product tends to look like the team that build it. So for example if each member of your team is holed up in their own office and only talks to other members of the team when absolutely necessary, your product is going to reflect that. You’ll end up with a disjointed product were each part feels separate from the others. Now a distributed team obviously doesn’t have to look like this. There are some additional hurdles that come from being distributed, but there are also many teams that have produced products that show the advantages of working in this way I think the reality of it comes down to understanding what your are trying to do and what kind of team you want to have and then utilizing the tools you have to help you work towards seeing that team come about.
One of the biggest challenges I’ve seen is what I would call the interrupt challenge. It is is tricky thing to balance out when you should or shouldn’t interrupt someone with a question. On the one hand we know that in order to get deep work done we (testers and developers) need significant periods of uninterrupted time, and yet on the other hand, it is easy to waste hours trying to figure out something that could be solved with a simple question to someone that knows. So finding that balance is hard. I think that in co-located scenarios we can tend to interrupt too often. It’s just too easy to walk up someone’s desk or pop your head over their cubicle wall and interrupt them.
However, in the distributed team setting, I think you end up with not enough interruption. For some reason it feels more intrusive to call someone on Skype than it does to stop by their desk and so we interrupt less often. This ends up causing several issues. For example this can sometimes lead to duplication of work. I don’t want to bother you with a question and so instead I start working on something that will solve my problem and end up doing so, but at the expense of having duplicated work you already did someplace else. It can also lead to poorly defined interaction points, where I make assumptions about what your code does based on reading it or observing it, instead of asking you about it. Now, hopefully most of those things are flushed out in code reviews but it is still likely that some things slip through which can only hurt the quality.
So what is a tester to do about it? How can a tester work in a way that makes a distributed team more effective? I think one of the important things to remember is that testers are often the glue between the various parts of the system. Although we may not understand the inner workings of the code, we use all the parts of the code and we have a pretty good idea of what will and will not work together. Getting the tester’s input early in the project is usually helpful, and so as a tester I need to the know that usually the most valuable time to ‘interrupt’ is right at the start. While the story is still being defined or as soon as possible after the developer has started working on it. Interruptions at that stage may save many headaches later on. This is especially important to remember when working on distributed teams were the desire to not interrupt can become stronger.
So what about you? What interrupt balance to you try for?
offbeattesting 