I recently interviewed Janet Gregory on the topic of distributed teams. Janet is the founder of DragonFire Inc., an agile quality process consultancy and training firm. Janet co-wrote the original book on agile testing “Agile Testing: A Practical Guide for Testers and Agile Teams” and the follow up “More Agile Testing: Learning Journeys for the Whole Team” with co-author Lisa Crispin.  Janet is a frequent speaker at agile and testing software conferences, and she is a major contributor to the North American agile testing community. We wanted to share that conversation with you.

Time Zones, Frustration and Trust

Christin: When we talk about outsourcing testing, a lot of the time that means we are talking about distributed teams. There are many challenges to address when dealing with a distributed team. A big one, for me personally, is working with the time differences.

I think it causes a lot strain and not only related to scheduling meetings. What is your experience around dealing with having parts of the team in different time zones?

Janet: One of the main things that testers do is give feedback. The shorter the feedback cycle, the more you can act on that feedback. As soon as you have time zone differences, it can lengthen that feedback cycle. Depending on the time zones, you can ask a question and the answer might not come back for 12 hours. Then, if you didn’t understand, if you didn’t agree or if you have a follow-up question, you can send your response and wait for 12 more hours to see what comes back. It can actually take days to come to a shared understanding about something.

If you have to wait even two days to get that common understanding, what does that actually cost you in wasted time, sending it back and forth, and waiting, and then task switching? That is very hard to quantify and a lot of organizations don’t take it into account.

Christin: It probably causes a fair bit of frustration too. People don’t particularly thrive in frustrating environments.

Janet: Right. They don’t. I’ve worked on both sides with a team onshore and the same team offshore. When you listen to the different perspectives, you see that frustration leads to lack of trust. The people onshore, for example, will say, “Why don’t they understand what I’m trying to say the first time?” The people who are offshore, they go, “They don’t understand what we have to deal with, why can’t they…” And every time they say that, the trust degrades a little bit more – the trust that the team needs to work together as a whole.

Christin: You can end up in a circle where it just keeps getting worse. So what can you do to make it better?

Janet: I just did a presentation on distributed teams. It’s not only testers that have these issues, it’s programmers and everybody. We all need to work to really understand the other team. What is their culture? What are their issues? So many words or expressions we use here in North America don’t translate. They are not comparable or there’s a different understanding of what they mean. We have to watch what we say.

To get a bit more detailed, specific tasks can help clarify things. For example, instead of saying, “This is the requirement, I want you to do this” we say, “This is the requirement and here are tests to show what I want.” If you give real examples with an expected output “this is what I put in, this is what I expect”. It really removes some of the misunderstandings. It becomes much more transparent, much more precise.

Christin: What you’re saying is to use testing and tests to facilitate communication and information sharing to some extent?

Janet: When you think about acceptance testing and development, that’s what they’re doing. We don’t use it enough across organizations or distributed teams.

Cost Savings

Christin: The next thing I am curious about from your experience is, companies that have tried offshoring. For some, it hasn’t worked as well as hoped, and they now look to take the work back. What is the main reason you think some stick with it and others don’t?

Janet: It’s kind of funny because you think people would learn, but there are still people who do offshoring because they are just trying to save money. Within 5 years, they bring the work back onshore because they find that it isn’t working.

I have seen teams that have made offshoring work but that’s in the instance where they cannot find people in their area. They’re doing it for that reason, not for cost savings. If a company does it for that reason, then they will spend the money to make it work. They will fly people in to meet the people at the offshore location. They will fly people from there to meet the people here. There is cross-pollination and they get to know each other better. That seems to help immensely.

They will also spend extra money on things like screen-sharing and collaboration tools. Whereas, when a company offshores just to save money, they don’t seem to do that. And then it fails. It fails because of the sorts of issues we have been talking about.

Tools or Tips

Christin: You mentioned collaboration tools in relation to making it work when you have a distributed team. Do you have any favourite or special tools that help build those remote and distributed relationships?

Janet: I don’t have any specific tools, but a couple of things that I’ve seen to be very effective are, for example, using avatars in whatever tools they’re using for stories or requirements.  For instance, Janet is working on a task and it shows a picture of me. It helps people realize that there is a real person on the other side and to develop a closer relationship.  When you do meet them face-to-face, you have that vision and feel like you already know them. Sometimes those little tiny things make all the difference in the world.

Another thing that I’ve seen is, it really doesn’t work when you’re 12 hours apart.  Let’s say that you’re only 4 hours apart and have a few hours of overlap. Then you can do things like a joint mind map. That way you can brainstorm with other people all on the same mind map. There are a number of those tools that exist now. You can see the updates. You can have a conversation going on at the same time. Lisa Crispin and I do this when we’re working on a new presentation or working on a book together. We had mind maps that we can work on together with a chat or voice tool. It feels like real-time. It feels like you’re together.

Christin: That can make a huge difference. Sometimes we focus on the big things that are hard to tackle.

Janet: Yes, sometimes it’s just the little things.

Conflict

Christin: What every workplace has, and most teams have experienced at one point, is conflict. I have actually never seen an example of an outspoken or acknowledged conflict for distributed teams. I’m wondering if we’re more reluctant to acknowledge that there is a conflict if we’re not co-located or if maybe we never reach that phase of team functionality where we go through the storming before we all settle down.

Janet: That’s an interesting thought. Let’s think about PQA. Your people in Halifax and your people in Vancouver have a 4 hour time difference – I’m going to guess what happens is that the folks in Halifax, would talk about an issue internally and then, if you’re really lucky, one person will be brave enough to phone one of you Vancouver guys and say, “Hey Christin, we have an issue.” But chances are, they just talk about it on their end and decide what to do or what not to do and never tell anyone else.

What happens if you don’t agree with somebody in Halifax about what they’re doing? You have an issue with him or what he’s doing. If you’re his boss, if he reports to you, that’s a different relationship because you have to do it. But if you were just peers, chances are, you can just avoid any conflict because it’s easy just to keep doing what you’re doing and just ignore him. It’s really easy to ignore your peer when he is not in your location. So the conflict might never come up. You can’t ignore it so easily when it’s in the same office. So that would be something that I would probably see happen. It’s a truly interesting question.

Christin: It’s something that bothers me because rather than talking about it when it is a small thing it grows into something huge.  I’ve seen examples of that in organizations that have offshored. It’s never said out loud, but it’s all based on a conflict that could have been resolved by talking about it earlier.

Janet: When I first talked about frustrations leading to distrust, I think that, in order to have a healthy conflict, healthy conversation, you have to have trust. So they might go hand in hand. I was just at my sister’s and we didn’t get along for many years. For the past few years, we have been working hard to build back up the relationship. When I was last there for a visit, we had a little conflict. It wasn’t the first one and it won’t be the last. But, it would have been easy for me to just have come home. Instead, we actually talked about it, and we came to a resolution. It took away a little bit of trust but we will work on that because we both recognize it. If we had not had that conversation, if I had come home and let that eat at me, by the next time I go to visit her it would have had time to really affect me and I would have treated her differently because of it. It’s the same with teams.

Management Responsibility

Christin: We have that added complexity of cultural differences too. How do we resolve conflicts across cultures? As a manager, or whoever owns this relationship, don’t you have the responsibility to be a little bit concerned if it seems that things are running too smoothly?

Janet: As a manger, that’s where you need to go and visit the different centers to be better able to understand what the nuances are because you won’t do it on the phone. You actually literally have to go and say, “What are you guys doing?” Just sit there for a few days to observe and watch. Talk to people. It comes back to the managers watching and being aware of what’s happening and then being able to say, “Hey, we have this. Let’s talk about it.” Being able to facilitate that, and kind of help to make that happen. Set up a safe environment, and safe is, no blame, being able to talk, to allow for it to actually happen. Unfortunately, there are many managers that don’t have that ability because they’re managers and not leaders.

Christin: In a lot of organizations, the only way to advance your career is to become a manager whether it is a fit for you or not. Not everyone even likes being a manager.

Janet: Me! That’s one of the reasons I became a contractor way back when because I just got really tired of managing, I didn’t like it. Now I can influence teams in a totally different way, but I don’t have to manage them.

Distance Learning

Christin: If you were working with a client that came to you and said, we really need help to test this project, we’re probably going to look at working with a vendor. What kind of advice would you give them, and what should they think about when working with a vendor?

Janet: If a company is looking for a vendor, I would want somebody who could work with a little bit of flexibility. Not someone who just said, this is what we have to offer, take it or leave it.  I would also really like to know their hiring practices, how do they know and, how do they make sure that their people are up to speed on it all. What are they doing to make sure their people are trained or kept up-to-date in newest methodologies, or whatever it is?   If somebody has been on contract for the last 2 years in one place, have they lost their ability to change or to do new things? That’s something I would definitely care about.

Christin: We encourage people to take training, both our clients and ourselves. For the latest trends on testing, or a hands-on how-to workshop, we know we need interaction with each other. Do you have tips on how to get people interacting with each other as peers, especially when they aren’t all in the same room?

Janet: When you’re distributed, it’s a little bit harder. For example, I’ve done distance coaching and I was in a situation with several people in one room with me and 3 remote people as well.  Interestingly enough, the people in the room, whom I could see were occasionally having side conversations with each other. The folks that were remote, every time they would speak, their picture would come up. They were not on webcam but their picture would come up so I would know who was talking. There was some kind of discussion in between with them but I think that the facilitator, rather than the presenter, could get both conversations happening. They could say, “Robert, that was a really interesting comment. What do the rest of you think?” Get them to talk to each other and then step back. It would be a very forced facilitation but that’s how it has to happen at the start.

Another thing to consider, is not saying “I’m presenting this so you can learn”. Some organizations I know have book clubs. They can say, “Our goal is to learn more about exploratory testing. Let’s take a look at Elisabeth Hendrickson‘s book and every week we’re going to have a discussion about a different chapter.” And then, you can make it more about the conversation between the people. What did they learn? What do they think about this? Instead of “I’m teaching you something.”

Christin: I like that idea! This chat has been very good for me. A very interesting conversation. I’ve got a lot of new ideas.

Janet: Excellent! I have written my own notes down too. That whole thing about conflict has got me thinking.

A Ph.D. particle physicist by training, Christin uses her scientific background and analytical skills to dissect complex software solution problems. Her career in the technology sector has primarily been spent in the professional services industry, starting as a quality assurance consultant and progressing through the different manager and director roles. As Director of Quality Engineering at Slalom Build, she is part of an incredible team of quality advocates, working collaboratively with clients to create groundbreaking products, while simultaneously advancing quality engineering practices.

LinkedIn: https://www.linkedin.com/in/christinwiedemann/
Twitter: https://twitter.com/c_wiedemann

Software tester Janet Gregory

Agile testing coach and practitioner Janet Gregory (@janetgregoryca) is the co-author of Agile Testing: A Practical Guide for Testers, More Agile Testing: Learning Journeys for the Whole Team and Agile Teams and a contributor to 97 Things Every Programmer Should Know. Janet specializes in showing agile teams how testers can add value in areas beyond critiquing the product. For the past ten years, she has been working with teams to transition to agile development. Janet teaches agile testing courses and tutorials worldwide, contributes articles to leading publications, and enjoys sharing her experiences at conferences and user group meetings worldwide. Find more information at http://www.janetgregory.ca and http://www.agiletester.ca.

Categories: Uncategorized