IBM's Elizabeth Woodward on Distributed Team Collaboration

1. What are the main problems faced by distributed teams?

I think the real problems faced by distributed teams are communication and collaboration, being able to work together across different cities, countries, continents when you are not in that face-to-face situation. Right now, I can see your reactions. I can tell if you are totally baffled by what I’m saying and I can tell if we’re making a connection. When we have a distributed team, they are missing that rich channel of communication. They are basing their conversation and understanding of off this other less rich channels, off of just the verbal or just the text document. They are making assumptions and trying to understand and relate based on that less rich channel. So I really think that out of all the challenges that’s the biggest one for distributed teams.

2. You mentioned some of the challenges around communication. What about collaboration?

Around collaboration - it’s one thing to be able to go and sit next to somebody and both of you be at the keyboard and you’re working through a difficult problem. Maybe one person is working on the keyboard and then you trade over to where the other person is working and you have that discussion. Walking up to a whiteboard and you’re diagramming and you are able to understand very quickly what the other person is trying to communicate through those very visual, tangible methods. When we’re working in a distributed environment, those can be real challenges if we don’t have ways to overcome those situations.

3. Let’s talk about some of those ways. How do you mitigate some of the problems for example with communication in distributed teams?

First of all, I think that the communication starts with when is the time when we are going to get together to communicate. We just start with that. We have teams that are spread over continents you are dealing with the time zone issues. So, it can be really easy to choose a form of communication that to where only part of the team is really present to hear the verbal side of it. Maybe you are communicating by an email message with the rest of the team. It can be really easy to say "OK, we’re in a distributed environment, this is how we’re going to handle it. We’re going to talk and we’ll send you email and you can keep in touch that way."

What that really does is it destroys the team working together and feeling very close-knit and part of a team. What we see is that teams that are really effective take turns at maybe meeting at a time that is less comfortable for them for the sake of teaming and they really value the other parties and the other team members’ contributions. They all make some adjustments to their schedules and the other team members in other areas will also make adjustments and they are sharing the pain in that area, but it also leads to a greater sense of teaming.

I have to tell you, with daily Scrums a while back, I heard a team say "We have a tool: we click off our tasks, so we don’t really have to meet for the daily Scrum and it’s hard and it’s inconvenient any way. The tool makes it all better." I think what we’re really missing there is the fact that we have to communicate; we have to understand where each other is coming from. We need that time when we’re together, understanding "What it this person working on? How can I help you? How can you help me and how can we together achieve these results?"

So, when I’m speaking to the daily Scrum it’s not really about clicking off tasks then allow me to let you know what my status is, it’s really about collaborating, working together and understanding how we can support each other to achieve our goals for that sprint.

4. Can you give a specific example from your experience about a distributed team that made that kind of compromise on time and had it really work well for them?

Absolutely. In fact, I have to tell you our team within Quality Software Engineering uses the same practices and we have team members that are spread across the United States. We’re in Austin, Texas we’re in Raleigh [NC], we’re in New York and we have folks that are also in China and India and Greece. We had a time where it was very difficult between China and the Central Time Zone in the United States to find the time that really worked well. There was more of this "I’ll put my notes some place, if I’m in the time zone that happens to be off and somebody will read them and the rest of the team will know what’s going on."

We really found that we were disconnected during those times. We felt less part of a team and I think it was reflected in how we ended our sprints. When you get to the demos and not everybody seems to be quite on the same page. We’ve personally experienced that. We feel closer and we know more about each other and we’re able to really achieve good results on keeping in touch in that way by adjusting.

5. Let’s talk about collaboration and how do you mitigate some of the problems standing from the need to collaborate across a distributed team.

You have to understand I’m very much focused on the principles and practices. I think that in order to be successful you really have to understand why you’re doing things. You have to have good fundamental practices and the tooling comes second. That said, when you are working in a distributed environment, you really need to have the tools in place that will help you to be successful. Things like a desktop sharing tool so that you can transfer control, so that you can both be on the same page. Some of the cool tools that are out that allow you both to edit a document at the same time or multiple people to edit a document.

Going to the task boards and being able to see the user stories and the tasks all on a physical board is really wonderful, but when we get to that distributed environment, we really need to have an effective tool where we can see our product backlog and we can see what the prioritization is. And we can work together when we’re getting ready to pull the stories up and define tasks and things where we can collaborate together and work on those things and see where we’re at together. The tools become important for that.

6. You mentioned the fundamental principles being very important. Give us a couple of examples of principles that you find to be crucial for good functioning with distributed teams.

I think in the Practical Guide to Distributed Scrum every chapter is focused on a different aspect of Scrum. What we’ve tried to do is we’ve tried to say "Here is this thing that you do, here is this meeting and here is why you have this meeting and here is what the purpose is." Out of that, you really have to understand what those core principles are, why you are doing this before you start making any changes or we get back into that daily Scrum situation I described to you, where "If I’m really only trying to tell you what tasks I’ve done, why can’t I just click this off?"

So every chapter, every point from what you need to have in place before you go into Sprint planning, why you need to have those things in place, understanding that before you start making changes in the name of helping a distributed team. There are adjustments that you have to make, but you really need to understand what the tradeoffs are before you start making those adjustments.

7. Let’s talk about some of those tradeoffs.

This isn’t technically Scrum, we’ll get into the practices, but let’s talk about estimating. Dealing with Agile estimation and planning, the whole team is going to be involved in estimation. We want to make sure that everybody who’s going to be involved in that user story is part of the estimating process as a good cross-functional group of people. Each of them is playing planning poker and we come to consensus on what the size of that story is. That’s the core principle of what we’re trying to do and there are reasons why we want to do that. We want to make sure that we get input from all these different roles so we really understand what has to be done.

We want to make sure that we understand all of those pieces and that’s all included in the relative size of what we’re doing. When we have a very large team, the chances that we’re going to be able to get everybody together at a certain time and everybody together is going to play planning poker on this particular story is probably not going to happen. We have to understand that if we’re going to pull together a subset of the people, what is the implication going to be? If we’re going to take a representative approach, we have 10 Scrum teams and we want to make sure that they’re all in synch and in harmony and we can include everybody in the estimation.

First of all we look at "Can we break that apart, smaller?" but the other thing we do is we say "If I have representatives coming together, the impact of that might be that we don’t have buy-in from the teams." So let’s make sure that, if we’re getting an estimate from representatives, that there is the connection back to the teams and that we have consistency and harmony and then we take their input into account and make the adjustments we need to make on that sizing. That’s one example. We hear some very command and control things, where not everybody could be involved, so certain people went in and they said "This is what the estimate is".

You take that back to the team and you don’t have the buy in. First of all, the estimate may not make any sense and the second part of that is you may not have the buy-in from the team that’s going to be doing the work. So you’ve not met some of those core principles. That’s what I was getting at.

8. You mentioned the book you came out with recently, A Practical Guide to Distributed Scrum. I understand you and your co-authors actually wrote that book as a distributed team. What was that like?

We did. I’ve been working with distributed teams almost exclusively since 2002. I just recently moved into a real office near real people, but pretty much everything that I’ve done has been with distributed teams. I know that there are people who say that you can’t really have a team if you are distributed or you don’t build those strong relationships. I’m sorry, that’s not true, you can. I’ve experienced some really great teams like that. Steffan Surdek is back in Canada and Matthew Ganis is in New York. The core three authors on the book, we worked together having the discussions, editing each other’s work by wiki or by document and change tracking and things like that.

It was a really good experience, we built some good bonds. On a broader level, this work really included the thoughts and ideas from people across IBM and outside of IBM, too. We made each chapter available for people to review and comment on. We had a lot of brainstorming sessions where we had people from across the globe, across different business units and brands, different perspectives from product development over to application development sharing their experiences and working together to develop content. What I think is incredible is you’re not bound by one person sitting right next to another. You are able to include people from all over to come up with something that’s better than what any one person brought to the table. That’s what I love about working as a distributed team.

9. Did you run into any speed bumps while writing the book that were related to the fact you were writing it as a distributed team?

Always. But I think it’s not so much working as a distributed team as working in a way that brings in different ideas and perspectives and respects that, and where it’s disagreement for the purpose of creating something new and better as opposed to "I’m right and you’re wrong. Which one is the right?" We have to have those discussions and really understand and see what the results are at the different actions and from that we can say "All of us together agree that this is probably a good way to proceed." The speed bumps were more about just that creative energy of the people with very different experiences and opinions coming together and sharing their ideas.

I think that’s one of the challenges of any sort of teaming. If it’s a really good team, you have strong people that are sharing their skills and experiences and you are trying to create something from that.

10. Let’s talk about Scrum specifically with respect to distributed teams. How does the Scrum Master’s role change when working with a distributed team? Is it exactly the same or is there some kind of change in the role that happens when you are actually working with a team that’s not collocated?

I really think you have to be an even stronger facilitator. Facilitation is the key to that Scrum Master role and when you get into the distributed environment where we’re meeting together, I get these visible clues from you. When you are on the phone, you don’t have those, you don’t have the safety net of being able to look over. Those Scrum Masters serving as facilitators and even other members of the team that are helping with facilitation really have to pick up some additional skills to be able to effectively facilitate by phone or to find those places where, if you have cultural differences, really understanding that and drawing that out and addressing it so that it becomes a positive experience for everybody on the team.

Those are the kinds of things. Silence on the phone - how do you deal with that? If you have somebody who’s very verbal - if we are sitting face to face, I can posture, I can turn my eyes to somebody else and let you know it’s somebody else’s turn to talk. But if we’re on the phone, and in fact there are some phones that won’t allow you to interrupt if somebody’s rambling, how do you deal with these things? Those additional facilitation skills are really important.

11. Let’s get very specific here. The phone is a very basic tool. Can you give a couple of ideas on how to use the phone effectively when you are working with a distributed team?

I sure can. I facilitate meetings all the time. I lead a lot of different communities and some this comes up really often. But there are some people who will have more trouble finding a quiet spot to interject their ideas or to share their ideas and opinions. It can be hard to figure out where to jump in. If you are sitting together, it becomes more obvious when a pause is about to happen, and you can ready yourself to be able to interject your thought. If you are on the phone, the facilitator needs to make sure that everybody is having a chance to bring in their ideas or their experiences and if people are not contributing, that facilitator needs to open up that space and give that individual the opportunity to share their thoughts in there.

I think that one of the keys is looking for people that may have good information to contribute, but are having trouble finding that slot time-wise to share their thoughts. Another one is when somebody is tending to go on, giving them that pause and saying "Those are really good. You had some great input there. Mary may have some thoughts on that. Mary?" Providing that transition, making sure that the person understands that they were heard, they you understood what they were saying and at the same time transitioning over to another person to give them an opportunity to include their ideas. There are so many things that we can talk about in that space, but those are a couple.

12. We talked about the Scrum Master’s role a little bit previously. How about the product owner? Does the product owner’s role change in a distributed team?

I think it really does. I think fundamentally it’s the same, but things like when we’re going into sprint planning making sure that if the team has questions there may be some time delays due to time zones and you want to make sure that there is enough time for them to follow up with stakeholders and bring the information back to the team. The product owner may be in a different time zone than where the team is, so there is doing some sprint preplanning, making sure that you get the input that you need so that the product owner can prioritize that backlog and get it into good condition for sprint planning.

That may be a longer process, just because of the different time zones. From a distributed perspective you just have to recognize that there may be those delays and expect that in how you’re addressing things like sprint planning. Then, of course we get to the part where identifying who the stakeholders are going to be for our demos, where you get into that whole question of "Are they a time zone that is going to be comfortable for the team?" or "How do we need to schedule that?", so those kind of things. It’s a little bit different than just walking over to somebody’s office or expecting that they’re going to be available during certain times.

13. There are certain ritual meetings that happen in Scrum, the demo being one of those. Are there changes that happen to those meetings that need to be incorporated into your plans for a distributed team? For example doing the demo online perhaps or something like that. Can you think of any differences?

That’s one. The other thing, we haven’t talked too much about this, but there may also be when we start getting into a distributed situation, we also start getting into some of the language situations and the cultural differences as well. But we’re previously maybe looking at let’s have the person that developed this piece or the person that was primarily responsible or some key contributor to this particular piece demonstrated this piece, now we have the question about the language skills - Is it comfortable for this person to be able to present? If not, what do we need to do differently in order to be able to have an effective demo? That’s one example.

And always, by all of these, the question too is meeting times. Then, probably the third one that I’ve mentioned is network latency and performance. Because you want to make sure that you have reasonable performance to be able to properly demonstrate what you are trying to demonstrate. I have seen teams very effectively do captures of a demo and made those available for downloads so that it’s very obvious what it really looks like without some horrible choppiness or difficulty getting to a server or whatever the issue might be.

14. We talked a lot about the disadvantages of distributed teams. Are there any advantages that distributed teams have over collocated teams that we should know about?

Yes. I think the biggest is (and I mentioned this earlier) is that you are not bound by how close amazing talent is to you. That’s my favorite. Regardless of where somebody sits, you can have access to that person’s amazing creativity and talent and experience and expertise. I think that will make your products better, I think it makes really anything that you’re doing better because you have access to skills that you otherwise might not have. So, for me that’s my absolute favorite of working with distributed teams. The other thing is that, besides the experience and the expertise and all of that, it’s the perspective.

When you are looking at working with people like we do, from different backgrounds, from different parts of the business, different parts of the world, there is a richness and perspective that either adds to the ability to be really innovative, that if you are always working with the people that are just like you, you don’t have access to that. From a competitive perspective, I think you kind of want to have that sort of access to that richness and expertise and experience.

15. Elisabeth Woodward, it’s been a pleasure. Thank you very much for speaking with us.

Thank you. It’s been a pleasure talking to you.