Scaling Done Right 11: Distributed Teams

Hello and welcome to the Scaling Done Right podcast. My name is Gerrin Hermkes and you're listening to episode 11 of this podcast, which is a companion to our book, the book that I and Lewis Cantella have written, which is also called Scaling Done Right how to Achieve Business Agility with Scrum at Scale and Make the Competition Irrelevant. Today we are going to talk about distributed teams. And this is always a favorite of people. This is a question that always comes up, how can I work with Scrum if I have a distributed team? And the simple answer is, and nobody wants to hear this, is you can, but you shouldn't, and you actually really shouldn't. Right? So I've worked with distributed teams and it has worked alright. But what we're saying in general is if the team is co located, meaning they're all in the same room, ideally in their own Scrum room, then velocity will double. And that is really crazy. And I wouldn't be surprised if it creates some resistance in you right now, because when people told me this, I was a bit resistant to that because I had a great team and it was spread all over Europe. And I think we did a really good job and we didn't let the fact that we were distributed keep us from doing good work and doing good Scrum. And so what we're not saying is it doesn't work because it does work. But what we're saying is that there are some factors that make team teams really a lot faster if the team is in the same location. And we think that it's sometimes easy to overlook the impact of these factors because they are a little bit softer. Right? It's not hard science, it's more psychology, sociology. But if you, if you aggregate them, they're going to have a, have a large impact. And so because everybody's still doing distributed teams, it might be helpful to talk a little bit about how to do it if you want to do it and you shouldn't. I'll say this again and again in this podcast, but you shouldn't if you can have everyone in the same room. So one thing that is important when you have distributed teams, it's actually not limited to distributed teams. You can have that on co located teams as well, but it's more bound to happen on distributed teams is a collision of cultures. And it's kind of funny because different cultures are often papered over, because if you work on a team, you will most likely share a language such as English. Right? And because we live in a globalized world, we all watch the same shows on Netflix, we listen to the same music. And so there's this top layer of culture that is truly globalized, especially knowledge workers. And that kind of keeps us from realizing that there's a deeper layer underneath it where our true culture is actually being shown. And these cultures might be very different. So for example, on the team that I was referring to, we had different nationalities from three different countries. It was Germany, Romania, Serbia. And while we all spoke English and participate in that global culture, the Serbian culture is very different from the German one. And actually, if we remember about 20 years, we were in a war against each other. And so, you know, you can always paper over that and not realize the profound impact that culture and history has on that. But it does. And if you don't address it, if you don't make it explicit, if you're not aware of it, you're probably going to run into problems that you otherwise wouldn't. And so this, you might have different nationalities in a co located team, right? But it's a different situation because the person, let's say a Serbian developer, would come to Germany and live here and be in our room, then he would start to adapt to German culture, he would learn more about it, he would find German friends, etc. While if he remains in Serbia, he's still entrenched in his old culture, as I'm in my German culture. Right. And so if you don't work on that national culture aspect, you are going to run into problems because you will be misinterpreting the things that people do or say. The way that I found is best to deal with that is get the book When Cultures Collide, which is really the seminal work in that space. And the book helps you to understand how cultures differ. That's the first part of the book. And the second part is actually an analysis of the top, I don't know, 120, 150 culture cultures in the world. So there's 10 pages that you can open up and read about Germans, right? What makes them tick, why do they want to be punctual? What do they like? What don't they like? What you should never say in front of them because it'll just make them irate and what you should do with them in business context, for example. And this is kind of a cheat sheet. And so what I'll do is I'll have people read their own first. So the Germans have to read the German so they understand themselves better. And usually when you can notice that people are reading this because they'll start to chuckle, because they realize that stuff that they thought before was their individual expression is actually just an expression of their national character, such as Germans complaining all the time. And so they read their own first and get some insight in how they are perceived by others. And then you read the chapters on the other cultures that are on the team. And this is extremely helpful because you get some awareness and you don't fall into certain traps. For example, like I just said, Germans tend to complain more than other cultures. If you're not German and you're working with one and that person keeps complaining, you might think that person is really unhappy or unsatisfied with your work. When in reality, complaining is a German's way of doing small talk. Germans are really bad in small talk. And so what we do instead is we complain about the weather, about politics or whatever, and it's a way of doing small talk. But if you don't know that, you'll think I'm about to jump off the bridge, or you'll think that I'm completely unsatisfied with the work you're doing. The other thing that you should be mindful of is language. It's true that, well, if you're on a team, it's very likely that you speak the same language. And if you don't, I'm sorry, I'm going to have to be adamant here. You have to change that because you're doing knowledge work. And if you don't even speak the same language, this is not going to work. You are going to lose so much velocity that from an investment perspective, it doesn't even make sense to have a team. You should break up the team and rearrange it in a different way so that people speak the same language. But even then, try to keep in mind that our language is infused culturally. So English, for example, is obviously Western centric. And so if you use a lot of idiomatic expressions, the tail wagging, the dog. Right, Stuff like that. And if you don't know it, it's like, what are you talking about? Where's the dog coming from? I thought we were talking about software. So if you use a lot of that and you're the native speaker or a native speaker on the team, please try to make your language easier, or maybe speak like you naturally would and then repeat what you've just said in more simple terms. And what I always try to tell people is I like to talk like that. I'm not a native English speaker, but I like to use Big words in English, right? It makes me feel good and I get to practice my English. But the problem is a Serbian might not understand that. And what I try to tell other people when I try to convince them of stopping this practice is imagine you're living in a Sinocentric world. And there you go again. Sinocentric is a big word, right? Sounds cool. I'm so clever. But nobody understands it. It means China centric. And so you can look at the world history and world events from a Chinese perspective, and suddenly it's not 1200 AD. Suddenly you're talking about some dynasty in China and you're not understanding anything anymore. Not because you don't speak the language or because you're dumb, but because that frame of reference is just foreign to you. So in your communication, keep out all those idioms, make it very simple for people to understand what you're actually talking about. And again, this can happen in a co located team as well, but. But it's more likely in a distributed team. Another aspect is the German term for Einheit. And Einheit is kind of like a. Like a mind meld or a unity of purpose. And it's something you have had Einheit with people, meaning you have probably been in trouble with a childhood friend, or you have been in tricky situation with a business partner or your spouse. And at some point of time after you've been through enough trouble and you know you can trust the person, you can actually read their mind. You know, if you're in a difficult meeting, you know exactly how that person is going to react, and the other person knows how you will react. And so there's kind of like a. It's not telepathy, obviously, but there's like a deeper understanding of how the other person is going to react. So you guys can play off each other. And that's Einheid, and that's what we want to have in teams. And Einheit can only be created. We want to have it because it's a shortcut. You don't have to talk everything out. I already know. Oh, Mike over there. Yes, he prefers to do it that way or he's going to go ballistic in a second. I know that. So I can actually intervene right now before we get into big trouble. Right. And so it's a shortcut. You don't have to make everything explicit anymore. You just kind of read each other's mind. And you can only create Einheid by having people go through experiences, challenging experiences together. And that usually means being together physically at Least for a while. And so we go into it a little bit more in the book. I just want to raise this topic so you are aware of it. But it's important to not just have the people never meet. And most teams during startup they will meet once and then maybe like, you know, once in a while and they drink a beer. But that's not how you create ironhide. You create iron height by actually challenging them as a team so they can see each other, how they react in challenging situations. And that's why some organizations pay for group activities. We have the example of dragon boat racing in the book where people have to race against each other in rowing boats. And it sounds, if somebody had told it to me I would have laughed about it and said this doesn't, this is not good. This is just some bullshit AR idea of team building that doesn't work. But it actually does. It actually, if you go through it and you're competing and it's wet and it's hot and you're sweating and you need to coordinate with the other team members and you have that pressure and it actually builds einheight, it actually builds that trust. It's not enough to completely build up einheight of course, but you have to invest in that to make it work. And. I want to talk about this investment because I think this is where a lot of the problems come from. Because we're doing scrum at scale here and we're talking about business agility. The things that I've been talking about were very practical. But if you take a step back and look at the investment proposition, the reason why a lot of teams are distributed is because managers want to take advantage of salary arbitrage, meaning they can find a developer of that quality for this price in Germany and have the price in India. And so they'll say, well, if the skill set is the same, let's take someone from India and they can just do their work over teams. The problem with that is that because they are not aware that co located teams double their velocity, they are making the wrong investment decision. So instead of having teams distributed and hiring someone on the cheap in India, it's much better to invest in a team, let's say in Germany, increase their salaries, give them the tools that they need, give them an air conditioning if they need it, give them the technical tools that they need. And in the end because of this effect that co located teams will double their velocity. They're actually going to be cheaper than having teams distributed all over the world. And if that's the case, you know, why not have one team in Germany and one team in India? Just don't mix them. And so while we're on this topic of geographical distribution, to wrap this episode up, I think it's very important to think, if you have to do distribution, it's very important to think about how you do it. And one of the core themes, one of the mega issues of Scrum at scale, is organizational refactoring. You have to reorganize the company to adapt to changing circumstances. You cannot remain monolithic in the same configuration for eternity. That's just not possible. And I would propose that one of the things or one of the ways in which you reorganize your company is to make it possible that people are co located. Ideally you would have all teams in one place. For big corporation, that's simply not possible. But what you could do is you can have all teams. So first of all, have all teams collocated in the sense that every team member is in one Scrum room. So there might be a team in Portugal, there might be a team in Romania, there might be a team in Stockholm, Sweden. Right? But please don't have like two members from Portugal on team one, two members from Portugal on team two. And like, don't make it more complicated than it has to have in one place. Have full teams and don't spread team members across the globe. So in a sense, you want to distribute teams but not team members, because that already makes everything much easier. And then also, if it's possible, think of the time zones. Keep everyone in, we call it a scaling zone. Keep everyone in within a band of a couple of time zones. So for example, if you keep all your teams in the United States, you are in the continental United States, I should say. You have four time zones, right? And in those four time zones you also have South America. So if you need cheaper labor, then it makes a lot of sense to get them from South America. And please don't lie to yourself. The developers in South America are just as good, just as disciplined. It's just a matter of getting there and getting them into your company. And so if you stay within those zones, you can actually coordinate the whole company much better than if you have developers in China, in India, maybe some in Europe. Because now you're inviting this trouble of the time zones into your organization where like people have to stay up during the night in the US west coast, they have to coordinate with India and you're just gonna, you're crossing the globe, you're truly global in your production when you don't have to be. And let's be honest, who actually has to be? The United States military has to do that. Diplomatic services, the news organization, they have to be global and they have to be active at all times. But normal organizations don't have to do that. So please stay within that boundary. If you are in Europe and you have three time zones, you can cover 2 billion people. I think if you include Africa. If you're in Asia, it's even easier just by using a couple of time zones, which is much easier to manage than using a time zone that's suddenly across the globe. You can have, I don't know, 4 billion people in that. And please don't tell me that you can find good developers among 4 billion people or 2 billion people, because you can. And by just having the team sit together in one room and only distributing the teams, but also only distributing them within a time scaling zone. So Europe and Africa, or North America, South America, you will actually be able to coordinate your company much better. Because you want succeed at business agility. If you distribute people across the globe as much as you possibly can, you might save a little bit on salary, but you won't achieve business agility. Alright, that's it for today. If you want to learn more about this stuff, we go into more detail in the book Scaling Done Right, which you can find wherever you buy books. If you need help with your transformation in the form of training, coaching or mentoring, please reach out to me garyonflow.net or lewis@ raskare. Com. See you next time.