 I don't do anything. So I want to interview you here on Radeco Collaboration by Ranjit Reedy. It's his first time presenting, so let's take that into consideration. Thank you. So let me begin the presentation. In this presentation, even though it's about agile, I won't be talking about scrum processors or the backlogs or the meetings that we typically schedule. It's more about how to do with people and how we solve the problems when walking with global teams. So a little bit of overview. I'm from the DevTools team. I'm the agile coach. So we are about 140 people. It's a very young team. We started about a year, probably. But the actual team started assembling about eight months. There are about 12 teams. And we have about six to eight months into agile because the teams keep building. And we have spread out about 10 countries. And even each team, there are about people from about five countries or six countries. So it's a truly global team. And there's no one team which is actually co-located in one country. So that is the background of our team. So I found it really hard, painful, and takes a lot of time. Which might be surprising because being Red Hat and being the leader in open source, collaboration is nothing new for us. We have been doing that for many years. But when agile is introduced, why is it so hard? It's not only about agile, but even I think in our particular team we are building services which probably will need continuous integration and continuous deployment. For that, we need teams which are able to work on a very tight timeline. And the way we built the team also comes into consideration because we kind of split up teams. We have some old Red Haters coming to our team. We have hired a lot of new people who are new to open source, new to agile. So there's people coming with different backgrounds, different mindsets, and we have to work collaboratively at the same time and everybody needs to be on the same page to be productive. So these are some of the challenges that I've listed which we found and we tried to tackle. Class system, time zone challenges, cultural differences, social distance, and cross talk. I'll go into details in the next slides. But why do things come in play? I think as part of being human, there are a lot of side effects that we kind of encounter. And I'm going to talk about them and see how we can go about solving for them. So when typically agile is introduced, people focus on the processes, tools, and practices. That solves only like probably one-tenth or one-twentieth of the problem. The actual value lies when we are able to change the mindset, the values, and the principles. This is a very nebulous area and people, that's why they should ignore it because it's difficult but it's the most valuable area for us to work in. So in our team, we kind of tried a lot of experiments. We split teams, we merge teams, we tried asynchronous meetings, synchronous meetings. We kind of, probably every month, we try new things. And whatever works in one team, we try to cross-pollinate it into other teams. So that's how we learned a few things and I'll share what we learned in our team. The class system. So basically this can manifest in many ways. It could be racial, ethnic, geographic, regional, product stickiness, dev versus QA. When it's a product stickiness, this is basically when we merge two teams who have been working on a product for two, three years, and we are trying to build a new system and try to integrate it. There's always a lot of resistance when we try to bring in their architecture into question or their design into question. They always feel that they are right and why are we changing this? So it's always us versus the new team. But to be collaborative, we always be on the same page. The same with Dev and QE. The way we solve this is instead of reporting structures, now they're part of the SCUM team, the QE. So we work as one team. That's how we solve that one. The other things we'll go into it slowly. So the one way to overcome power balance is to collect the power imbalance. So what I mean by this is because we are geographically distributed, if all the leads, all the managers, everybody is sitting in Westford and you're only hiring developers in India, there's great power imbalance. People will feel that they don't have a voice. And if you're able to bring in some leadership in the other teams also, then the power imbalance will be corrected and all those biases will kind of slowly be eliminated. And of course, sometimes it feels silly when some of the comments are made, but I think when we take into consideration from the guy or the girl, from the receiving end, I think it looks very different. So I think basically having a zero tolerance policy really helps in this area. This is self-explanatory, so I won't spend much time on this one. Now, when we are merging teams and they're sitting in different geographic areas with different cultures, different backgrounds, different mindsets, it's very difficult for them to work as one team. So I think if you keep reiterating that we are one team and we also, if you bring in the competitive spirit, that automatically I've seen it helps a lot. For example, in our space, we've seen GitHub, GitLab coming up with similar products. We've seen IBM coming up with similar products. So this urgency that we have and this sense of competition that we need to meet the timelines kind of really helps for everybody to come together and work as one team. Coming to the time zone challenges, this has been really challenging for us because we have spread about 10 countries and at least each team has 5 or 6 countries. So the way we have solved this problem is we tried to see what is the overlap because when we take into consideration like West 4 which is East Coast, US, India and Bruno, for example, we found there's only a 3-hour overlap which is kind of suitable for everybody because when it's early about 8 o'clock in US Eastern, it's probably around 6.30 in India and later we push it. If we don't want the team to kind of burn the midnight oil and if we want them to leave at 9.30 or 10 in the night, this is only 3 hours we have. And the other thing we did is we fixed whatever scrum meetings that we needed to do for only 2 days in a week. So it's Tuesdays and Wednesdays are what we fixed and 3 hours that's it and that's every week. So what this does is it frees up a lot of time for development because one of the biggest complaints when we talk about Agile or Scrum is everybody complains of more meetings. So the way we solved it is we kind of fixed it to 3 hours in 2 days per week and that kind of repeats every week. So by having a pre-determined fixed schedule everybody knows that this is the best opportunity for them to collaborate or meet so that they don't have to have ad hoc meetings or interrupt others during the day when they're actually being productive and their best coding time or whatever. So we leave them as much free time as possible and this seems to be working and we've kind of unilaterally made this as a structure for all our teams and if they need, they're free to set up their own meetings on the team level but on an overall program level this is what we follow. I think this is an article that Jim mentioned or CEO mentioned that we are free to talk in a way because the redact culture is basically the code is that's the dumbest idea I've ever heard. I can't believe that you're such a moron. I think it works when you're in the same team in the same colocation but when you're working across different countries if I call you a moron when the first or second time if you haven't even met your face-to-face it comes out across very differently and especially in the written format and the text thing or in the emails it seems very disruptive and kind of insulting. So I think unless you build that familiarity with the person or the team I think we should tone down on the language. I know we want to bring our hearts to redact and kind of have an open, energetic discussion but as much as possible until you bond with the team and very close to them I think it's better to refrain from using language or cussing which kind of goes... This is something a little different maybe a little controversial in redact but I think it helps at least in the initial stages. Coming to cultural differences when we have these blue jeans meetings or video conferences it's very difficult to see if the person is agreeing with you and the best thing is to take away assumptions from it. So silence is not equal to consent and nodding is not equal to agreement. A lot of people make fun of Indians because we especially when yes or no we have to say yes and no so it's very confusing for people. So the best way to avoid this maybe incorporate things like dot voting or get a spreadsheet and let them say yes or no, yes or no that way it's best to take away any ambiguity if the team is on board or not. Now conquering social distance unless we feel close to the people that we work with we really wouldn't go the extra distance and we really wouldn't have empathy with them and the best way to we have done is we have a lot of face-to-face meetings and we also invest a lot of unstructured time in this face-to-face meetings. So we go out as a team we have activities other than the typical meetings that we have because small talk is powerful that's where we actually get to know people. For example, you know if your parent you love talking about kids and we are all more alike than we are different the first impressions we always notice the differences whether you're if you're short you notice that the person is tall or if you're so but after we talk you realize how similar you are so if your parent you talk about kids or you know if you're married you can talk about how evil your spouse is these are things that you know basically you've gone over so and we also it's best that you know you have this activity stories experiences and photographs these all help in getting the shared memories of the team and a lot of times we have people coming over to India spend a few weeks just not for the meetings but they stay there they get to know the people and I think that's been really helping because a lot of time when you have these strong arguments you necessarily see the other person as someone autocratic or you know not willing to entertain someone's ideas but when you spend so much time with them you also realize that's because the case so much about the product or the team that they're really passionate about it so having that kind of interaction is really important now cross talk so you know having coming from different so many different countries we definitely hear a lot of heavy accents and we're dealing with such complex ideas because we're building cutting edge stuff and less fluent English speakers all this makes it very difficult for us to communicate and especially when we're doing it over a video conference or email or chat especially the voice part it's been as a coach I kind of attended a lot of meetings and I see a lot of people are very frustrated and they kind of shut down people not because of their ideas because they're not able to follow what the other person is saying and I think the best way I mean the couple of ways to handle it I think most of the things are kind of also talked about very publicly like public speaking like actively use whiteboards or slowing down the speaking space rephrasing the content and always seek confirmation that what we talked about these are couple of things that would really help and because this is a real problem and I think once we kind of start putting in kind of make an active effort it really helps for the team to communicate better and this is something that we recently introduced our new performance review process so what we have done is now we have rapid feedback cycles in some yearly reviews we are doing it in every two spins what that does is whenever you kind of give evaluation for the team and every two spins they're motivated and they're able to change their behavior so this is also I think a very pleasant change that we have observed and I think we'll soon be seeing a lot of change in the team once we see the rapid feedback looks kicking in that's all I had to offer any questions so this goes back to saying that not taking silence for an answer saying that they're on board so that way you basically do a dot voting or something so you know the people who have signed up first they're on board or not we have a three weeks come cycle but most of the yes why do you decide like two days that are together and not space so something that been experimented with so Mondays we didn't want to have anything and Fridays most of the people are out so we thought on Thursdays is something that we wanted to give people for their own development and then Tuesday works best because the way we also structure our scrum it ends on a Tuesday it starts on Wednesday so all the retrospectives and everything happen on Tuesday and planning meetings happen on Wednesday so that kind of helps us to be seamless so can you say what scrum works for your team? it's working for most of our teams some of we are still improving and we've also given a lot of we have not enforced strictly how the teams implement the scrums we've given a structure that people are free to kind of tweak so specially teams which are working in upstream they have a challenge where they you know can't depend on their own team right working on someone else to merge the PRs so they have a little more liberty as to how they would like to work in the framework these are the typical meetings that we have are the planning meeting the retrospective so I think if you're looking for number of hours per week it probably comes down to the three week sprint cycle 4.5 hours is what we have seen that what we have allocated for these meetings scrum related meetings your leads have a little more because they also have to attend the scrum of scrums where we all collaborate as the 12 teams collaborate together because there's always interdependency between different teams yeah we we have shifting to matter most right now but we have used chat services as one of the means hip chat or Slack and sometimes we've also tried the stand-ups on those things instead of actually meeting because sometimes it's very difficult for all the people in different times to come together and Blue Jeans definitely is one of the most of the meetings that happen meetings everything we use Blue Jeans for that very similar working teams we have some of the same challenges we haven't been able to ever implement scrum across geography I'm curious whether you think that has gone well or you've just been able to sort of power through at least the time shift becomes a blocker to effective stand-ups some people will have to stand in right before they're having dinner coffee at the same time it just seems to fall flat yes so we did that we gave full freedom to the teams to choose how they wanted to do it but what the teams themselves realized as some of the teams came back saying this is not working because when you have an unsignificant stand-up people the what people have said might you know the person might be gone if the status isn't gone and you might not be able to follow up with him so they have actually gone back to face-to-face meetings even though that means maybe one or two people might not be able to join because it's probably 5 a.m. for them so it's kind of a balance that they're doing and I think two or three teams have come back to face-to-face after trying their synchronous because it doesn't seem to be working as well as face-to-face because people are quite silent and they are rather like mothons of singing how do you encourage to participate in dialogue at least at Red Hat I haven't seen too much of the silent type because I think the people they bring in are really passionate about what they believe in and even especially in India where people tend to be a little more silent what I've seen is that really outspoken and they also of course the people who are young like who bring in like interns they have to develop that culture but once they see their peers doing that and I think our leaders also encourage their behavior a lot for example me, they have asked me to come and speak here I'm an introvert as well but this is kind of helping me to speak up as well so I think it goes back to the leadership to encourage the teams and ask them to speak out so face-to-face as in like physical face-to-face meetings or? okay the typical meetings that we have face-to-face when I say are the ones that I'm saying where actually physically people meet so that way you get to know each other and we have quarterly planning meetings that happen wherein everybody for example after this DEF CONFIA meeting three days in the Bruno office where all the leads from all the countries fly over and we basically kind of plan together so that's one kind of face-to-face that we do another one is of course typically or blue jeans for the weekly meetings that we have to handle any other questions? I think this is a problem probably across Red Hat I think some of the old ways we work in Red Hat I think there's a lot of resistance to shift to the new way of doing things because I think it's because it works so well for them and they're I think change is always hard and if you've been successful doing things the other way you always tend to be more resistant because you know that something works but the problem with the old way of doing things in the open source world we're collaborative but I think you typically always the team that you have working collaboratively already have a common purpose so it's much more easier for example like you're working on a kernel you interact with people who already are interested in working on a kernel but in our case when we are building totally new products we are hiring people from different backgrounds and mindsets and that means we also need to carry them with us so it's not enough to have all the information in your head you need to put it down somewhere and it comes on the same page I think that's one change the challenge that I'm saying from especially the old Red Haters one last question balance so he's able to speak out whenever there's something wrong or when someone's voice is not being heard and I think that's been a very important thing that we did to correct those power imbalances at least the majority of the team is right depends how many people are there remote is and all that it's not possible but at least wherever there are a lot of people focus