My 5 tips when working with distributed testing teams

Times have changed, and so has Team Geography

distributed testing teamsNot too long ago, when you said you were part of a global software development team it meant that you were working for IBM, SAP or one of only a number of Fortune 100 companies that had development centers around the world.

Today, even companies with less than 10 employees can have teams distributed in two, five or more geographical places.  The location of team members has become an accidental attribute, often disregarded or altogether ignored.

If you add to this alternative testing or development sources such as Offshoring, Outsourcing or even (one of my favorites) Crowdsourcing, it becomes apparent that only a small percentage of companies today are still doing 100% in-house development and testing, like we used to do in the “good old days”.

Managing distributed teams was and still is challenging

About 13 years ago I was introduced to the concept of offshore management.  As a young QA Manager I remember how excited I was when my boss told me that I would start managing, in addition to my local team of testers, a group of 6 test engineers in another country.  This was an experiment on offshoring (actually it was outsourcing) that my company wanted to do, and me and my team were chosen as the company guinea pigs.

I only thought of how much more I would be able to do now that I had a bigger team, and I completely failed to realize that this happiness came with a significant price tag.  Within a couple of weeks I understood that managing a remote team was at least 10 times harder than managing engineers sitting next to me.

My main challenges (mistakes?) came from not understanding how my extended team actually thought and worked.  The cultural differences, together with the difficulties in communication, made it close to impossible to get visibility into what they did and how they did it.communication

To cut to the chase, after 6 months of struggling I asked my manager to close down the experiment, as it was taking me more time to manage them than I was gaining from their overall work.

5 tips for succeeding with distributed teams

Throughout the years I’ve had plenty of chances to redeem myself from my first failed attempt at outsourcing, and I’ve worked out a list of tips that today help me approach these project correctly and succeed in leveraging the potential of my distributed development and testing teams.

Here are my 5 tips to succeed when embarking in any distributed team project:

Tip No 1
Ensure communication redundancy

When working on-premesis each of us has plenty of ways to communicate with the other team members.  We can talk during regular meetings, jump to the cube of a peer, send him an email, leave a hand written note on his desk, or even go out to coffee or lunch and talk about stuff we prefer not to talk during “regular work hours”.

I remember working on a team in particular where the important decisions and the revolutionary ideas were reviewed and closed “informally” while smoking in the parking lot at 8:00 PM after the end of the working day…

This is simply not the possible when you work with distributed teams.

The point is that since not all messages can be convene through the same channel it is important to make sure you have in place multiple channels of communication, and that these channels are available to communicate with all team members (regardless of their jobs or ranks).

Some practical ideas:
– Create a list of all team members where you have all the ways to contact each person including office phone number, mobile number, mail, Skype, etc.  Add some personal info as well, starting with a picture of the person, date of birth, hobbies, marital status, etc.
– As a manager make it a habit to start your day by greeting your off-site team members via Skype, just like you do with your on-site team when you make your morning coffee or walk by their cubicles.
– Encourage your team to use the phone or Skype instead of emails to ask quick one-to-one questions.  A big mistake done by many people today is to use long email chains (that expand over hours or days) instead of picking up the phone and solving the issue in 2 to 5 minutes.
–  Video conference as much as possible, body language is as important (or more) than verbal language.  With Skype, GoToMeeting, FaceTime and all the rest of the communication systems it is as easier and cheaper than picking up the phone.

 

Tip No 2
Make sure everyone knows what everyone else is working on

Take 30 minutes each morning (or afternoon, depending on where the other teams are) to have a synchronization meeting where each team member will say what he did yesterday and what is his task for the day.  Make sure everyone knows what everyone else is working on and encourage engineers to provide feedback and help other team members, regardless if they are in the same site or not.

If you are working on an Agile environment this will probably be your standard “Daily”, but most teams don’t work this way.

Still, regardless if you are working Agile, Waterfall or using your own methodology, this type of synchronization meeting will allow your individual team members to feel they are involved and are part of each other’s work.

It will also allow you as manager to know what each team member is doing and what are his challenges, without needing to micro-manage their work.

One thing to take into account is to keep these meetings short and focused.  If they become endless and boring discussions between specific members of the team or updates where no one else is paying attention to what the others are saying then they will become more harmful than helpful…

 

Tip No 3
There is no replacement for personal contact

There’s no way around it, the best way to get to know someone is by meeting him in person and spending some time together.

Hand shake

If you’ve been placed in charge of a remote team, schedule a trip and go to meet them in person as soon as possible.  It will show them you care and are interested in the team and what they are doing.

Make sure personal meetings are not limited to managers.  Put in place an exchange program where engineers from all sites go and work with other teams for 2 or 3 weeks once a year.

This will allow people to get to know each other personally, and will help to share work dynamics, methodologies and even the challenges each of the teams experiences as part of their day-to-day operation.

 

Tip No 4
Manage your work on a single platform

If you want your team to work together they need to “talk the same work language” – and I don’t mean switching to English!!!

Centralize their work on a single management platform, this will give them a “shared language” to communicate and work.

Switching to a unified platform is not trivial and there are a number things you should to take into account along this process:

  • The platform should be accessible and comfortable to all members on all sites.  Make sure that things like accessibility and response time will not make it frustrating to work for testers on remote locations.
  • The idea of the platform is for all teams to work in a similar fashion, so it should accommodate the methodology of all teams and be customizable to needs of all.
  • Organize the information in ways that will let all engineers access the information from all the teams and be able to leverage it for their own work.

Once you are working on a single platform find ways to encourage people to access and use the information from the other teams.  This will help team to relate to one another and will trigger a direct feedback process between the teams.

 

Tip No 5
Make sure the “away” team is 100% identified with the project/product

When you have a number of teams working together there is always one (or more) that will feel “away” or “disconnected”.

There are many reasons for this, maybe because only one of the testing teams is working on the same site as the development team and they are “closer” to the developers, or because one of the teams sits in the site of corporate headquarters, or simply because one team is bigger and “older” than the other.

Whatever the reason this can cause the feeling of one team that is closer and the other further away from the “action”.

There are a number of things you can do to work on this feelings and improve the attitude of the other team, for example:
– Make sure to let the testers of the “away” team have direct access to the developers they are working with.  Do this via Skype, video conferences, etc.
– Set weekly update video meetings with people from the company that are not related to the development such as marketing, finance, sales, etc. where they talk about how other teams work, what are their challenges, etc.

Whatever the issue, something that always works for me is “merchandising”!
YES, as simple as bringing them corporate notebooks and pens, making sure they have corporate posters on their walls, giving away t-shirts or stickers or any other type of brand or corporate merchandise has a very positive effect on the way your “remote” team will identify with the Company.

 

Working on the psychological and physical level

To summarize, if you want to succeed on your distributed project you need to remember to bridge over the the psychological as well as the physical barriers affecting your collaboration and communication.

Treating only one of these aspects while leaving the other one unattended will ultimately cause you to fail.

Do you have other ideas and tips that can help to succeed on distributed projects?
Please share them with us!

 

(*Images by FreeDigitalPhotos.net)

,

  • Hey Joel,
    That’s a really good post (really liked the Exchange program term – and it should include developers, system engineers marketing and such too), 
    I think a main issue is indeed cultural training of both “country” habits as well as “company” habits.
    Discussing expectation is another important thing, often interleaved with cultural differences.
    While video communication is supposed to be easy – for some reason with all the advanced technology, still in many cases just setting a remote meeting takes half an hour – 
    Preferably leave a dedicated PC in each meeting room, all set for communication, and find means to pass other information from personal laptops through it.
    Verify someone is in charge of these meeting rooms on both sides – and verifies at least twice a day that all is set up right (and no one has changed anything which will set back the next meeting).
    Remote debriefing should be encouraged, as this is another way for knowledge transfer – and again the participants should change from one meeting to the other – covering all employees.
    In initial stages, it is often wise to have an activity leader from each side – visiting the other site for long term (in many cases the costs of this are not taken into account).
    This can also be used for bridging the week days differences, other wise a person of each “missing” group on that site should be there to support other groups (if there are only testers on the site – one developer should be there for initial assist also on weekend days of the other group)
    Common Lectures, and or shared recorded weekly lectures help passing the knowledge, and creating a repository of knowledge for newcomers.
    When we talk about testing, then design for testability is even more important – easing the way to gather information required for bug investigation, clearer logs and such tools are very important.

    Thanks,
    @halperinko – Kobi Halperin

  • joelmonte

    Thanks Kobi!

    I think you touch some pretty special points, specially the one of mutual cultural adaptation.  Many times we take it for granted that “the other side” understands the way we think, talk and act, but in fact we are sending them mixed signals that just make the communication even harder.

    Again, thanks for your input and ideas!

    -joel

  • Pingback: Five Blogs – 17 July 2012 « 5blogs()

  • Kuznetsova Victoria

    Hi, Joel. Great post!

    I want to add that in my experience when there is a core team at headquarters and an outsourced team in some other city there is often a problem of team qualification levels. Outsourcers are often less experienced and qualified then the core team. As a result, developers and testers in the core team feel frustrated and annoyed because outsourcers slow them down and take their time for nothing, and outsourcers feel that attitude and feel offended by it. Developers may even form an opinion that this particular tester’s bug reports have no value at all.
     
    Because people in this situation don’t really see each other and only communicate by and for work, it becomes a real problem if not dealt with.

    What I suggest is a trivial thing, but it is often neglected in the name of time-savings: when a new outsource team members join a department, it is necessary to intensively train them for a while so they can work on the same (or close) level as others. Before they are ready it is better to make them work through a superviser who will review their bugs before developers and other testers see them. Though this increases time for the whole teams to fully integrate, it also decreases mutual frustration when integration finally happens.

  • joelmonte

    Thanks Victoria!

    Nice tip, don’t forget to train properly!

    I remember that in one company we used to send someone to the “away” team for 3 to 5 weeks whenever more than 3 new engineers joined specially to do that.  Now that you mention it, this person also served as their “supervisor” or at least he checked their bugs and tests and was in charge of giving them direct feedback before their “stuff” was given to the rest of the team.  Sounds similar, right?

    In any case, thanks for sharing your tip!!

    -joel

  • Kuznetsova Victoria

    >Sounds similar, right?
    Totally. 🙂
    3-5 weeks of on-site training sounds great! I wish we had such a practice when we started to work with outsource teams.

  • joelmonte

    🙂

Shares