My 5 tips when working with distributed testing teams
Times have changed, and so has Team Geography
Not 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 challeging
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.
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.
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!
