 Okay, so I hope everybody can hear me Then let's get started. So I'm you go messer. I Have been working with India for 10 or 12 years now So I've got a lot of experience on working with distributed teams and distributed agile So my talk today will be about the top five problems that I've actually Encounted myself and I've seen other people struggle with if we work with distributed agile teams Yeah, first question. I often get is what do you mean by distributed? So we can make a whole theoretical approach showing these quadrants This is from Johanna Rotman and she takes the 60 meters approach so she says okay if you're in one building or like in one city And we've got two buildings then you might call a distributed My my my answer to a distributed or the way I see distributed is when we have people in other countries Like we have other time zones other cultures So when I talk about distributed that is that is what I'm referring to because I think if you were in the same country in the Same city you can still meet up You're talking the same language and it's a lot easier to organize stuff to collaborate co-located But if you have India Holland for example, it's a lot more complicated. Yeah, so that's my perspective here So I'll walk you through my own personal story and the five problems as I have distilled them over the last You know, let's say 10 or 12 years I'll share some things that helps me because there is no magic bullet. I don't think there is any framework or Model like scrum. Okay. Do this for agile or for distributed teams and it will work. Unfortunately. It's not then I think it will never be invented I'll share some tools that you might be able to use in your own Practice and then I'll wrap up. I've got about 20 minutes, which is pretty short normally. I have longer, but let's see where we get so This is my country I'm from Holland and you know, there's not so many places where it looks like this A lot of people think we walk in wooden shoes and we have a lot of windmills There are some places where it looks like this, but often it's very gray sky. It rains a lot We've got a lot of wind So last year I decided to replace my environment and I now live in Bali So it's I took it from the Internet, but it looks somewhat like this in 2004 I made a trip to India and I had already in my mind to start an outsourcing company because in that period all the US companies started Outsourcing to India and I figured that Europe usually is two or three years later than the US So if the Americans were doing it, I thought the Dutch or the Europeans would start doing the same thing Is it funny? And it was actually about right Because right now there's a lot of Dutch companies doing outsourcing and it's very common shell is there a lot of ING Bank will have a talk tomorrow So this is me in the Rajasthan desert thinking about how it would you know start a company around this model Like what could I do? I had no experience. I didn't know anything about software. I didn't have any contacts So that doesn't help me a lot and when I came back. I started bridge global Initially, I was an intermediary So I took projects from companies in Holland and then outsourced that to suppliers in Ukraine I chose Ukraine because I thought it would be closer by culturally geographically time difference is only one hour And I also learned that if I work with it I spend three months in India traveling around and I figured that it would be very challenging to work with a culture That is so different from what we're used to at least in my perspective in Holland I See that differently right now because I actually believe you can work with any culture. It just takes a little bit of time and practice So that company I started as an intermediary and now right now We have own offices in Ukraine and India most of the most of my people are in India now In that first period from 2005 to 10 I cried many times Because I think I must have made all the mistakes that you could possibly make in that situation because I didn't know anything about it The outsourcing didn't know about software development. Everything was still waterfall in that period So some of the things that I encountered so what I first did is I thought okay If I put a project manager in between my clients and my Ukraine teams or my Indian teams She could actually solve everything because she speaks the same language She can go out for lunch with my clients and everything will work out fine So she she took bright like the big requirements documents from my clients send that to my teams in Ukraine And then they made an estimate that made a planning a proposal etc all fine And then she was managing it now my you know, it's not a scientific thing But I think 80% of the projects in such model work Okay, and then 10% you know you have a lot of pain and you finish it But the last 10% brings you to a courtroom somewhere because you can't finish it So early on I concluded okay fixed-price waterfall base projects is not really the way to go So the first generic thing that I see and is it this is true for a fixed-price waterfall project And it is still there if you do agile The teams are often in the dark So you get your big requirements documents Which is made by some brain somewhere in let's say the US and that brain puts it into a documents and send this To India and in India some other brains are going to look at this and try to understand what that guy has in mind But it's not easy because we have to read everything and we don't know if you wrote down the right things As a team remotely we also don't know what the product is about we don't talk to the users We're not close to the stakeholders. We might be like if it's an insurance product We might have a totally different system in India versus the US So we don't understand the domain or the context so that brings that team kind of in the dark The second thing is if you look at it from the client perspective or the outsourcer perspective on shore It's sort of a black box. So I take my requirements. I send it into that black box Some smart people that do work in their ways, you know, they organize and they make the work happen But I've got no idea who is working on those projects or how they are doing the work Yeah, so I'm relying on that black box Ideally I want to open that black box which agile does Because we have way more interaction. We don't make the big requirements documents So that helps a lot but in a lot of cases, you know People don't that to go into the airplane and they still sit far away and they see in the eyes of black box So I think this is still a big problem So when I learned that I thought okay, let's do it in another way So I hired these guys and I made them work for my my client in a dedicated team They were not so good yet, by the way So I figured okay if I have a product client a product that we're building a product for a client Be it a product company or an enterprise building their own product and I've got a dedicated team Continuously working for that product on the longer term It would work a lot better and it actually does because you get more of a partnership or a sense of being one team So I think this model is a lot better than using this black box waterfall approach The issue that I had personally in that case was I wasn't intermediary at that moment So the clients were working with my suppliers and of course I brought them to the best suppliers in your green But after three months they would come lock on my door and they said you brought me to these great guys But you're actually not adding value. So we decided to work directly. So from next month. We won't pay you again I thought okay That's not nice. So I went to India in 2008 with my family I I don't wear this regularly, but in Kerala where our office is they wear this This was a wedding of one of my colleagues and this is my wife and two kids in that period And I went to India for one and a half year to set up our office And that's the same so I did it completely from scratch You know hired people and found an office which I don't advise to do like that because it's not that easy And I also started partnerships in Ukraine and Moldova So I set up joint ventures with companies that I had worked with before and in this case I had more control over who was working for me and my clients perceived Everything as being bridge. So they didn't go behind my back because they couldn't they could still program us But most people don't react to that I found now this didn't solve all the issues because one of the things that you have if you Make a client work or onshore team work directly with an offshore team Articultural differences, I don't want to explain too much about this But one of the things people in India tend to do is throw colors at each other. So that's something we're not used to in the West You're also used a lot to hierarchy at a society in India is much more hierarchical So people are used to getting orders from bosses or from teachers or from that's Where they hope the whole system is different and if I'm a Dutch and in Holland We try to organize everything in a very flat way. So If you make a Dutch work with an Indian team, they have to get used to that because yeah It requires a different way of organizing, especially if you do agile We we rely on people not waiting for instructions We want people to be proactive and take their own responsibility Yeah, so you need to educate and train people on the Indian side on both sides by the way to get to that level Another thing I noticed is that openness is a big issue Now we Dutch are very famous to be a little bit too open sometimes yeah to the extent of being blunt I've learned that this is not always the right approach because you might insult people and they will still smile Still you might have insulted them. So I learned that Being open is is actually good. This is one of the core values in our company as well But it takes time to get people to that level and if you get people to understand what openness can bring It's also one of the core values of scrum if people are open about being stuck or not understanding something It makes it easier to collaborate with other cultures But still it takes time and you need to work on that The fourth thing I found is that you often get a us versus them mentality So if we're in the US and we outsource to those guys over there in India, then if something goes wrong Those Indians did it wrong That's what what tends to happen sounds familiar. I think So as soon as that happens you try you get a separate Yeah, you get you get a big divide and the relationship be it within one enterprise or client vendor. It drives things apart Whereas you want to be partner you want to you want everything to be one So if I notice this within the collaboration with one of our clients It's a big red flag and I know I have to start working on the mindset and the way we collaborate Because you can't fix this in a contract Fifth thing is and this is surprising we stop communicating if we're in one office we Meet each other very regularly. We have lunch. We have coffee. We have all our roadmaps and product visions on the wall And everybody can see this but our remote teams can't see that we don't we don't meet regularly So even though we have Skype we have what's up We have slack there's a lot of ways to communicate people tend to to communicate less than if they're in the same Office whereas they need to communicate more And I think this is a very big thing It's very easy to just put up a screen and have a continuous video conference with your team in India But I don't see many companies do that a few weeks back I was in a big bank in Jakarta and I see they work with you know, Hungary Jakarta Which doesn't make sense to me but they do and then they have Skype calls with 15 people on the Jakarta site and then two teams in Hungary all through Skype connection with a small screen like this and Everybody everybody is asking you okay. Can you hear me? Can you hear me? I think it's 2017. Why do we do this? So I think this is a major thing and even with all the money and communication models. We're still not doing this We're not communicating so In the years after that 2010 to 15 I started learning a lot on what not to do how to avoid these issues So my company started growing. I learned I learned a lot myself and one of the things we did in 2011 or 12, I believe is to start with Scrum, you know, I Hear a lot of you know feed negative things about Scrum about the certification Especially in this conference and I think in a way I understand why but I also think this actually brings a lot of value Worldwide I mean Microsoft made Standards for PCs. You know, everybody thinks Microsoft is bad But they actually enabled us to have one platform to communicate through a system if they hadn't been there Where would we be today? So I think Scrum is doing somewhat similar, you know Everybody worldwide Understand Scrum. It's easy to learn. It's easy to start with and that helps companies to collaborate So and also the you know meeting rhythm that you have within Scrum helps so much if you have people on different locations The other thing is self-organization for me that has been a eye-opener because again if in India It's very common to be Hyoarchical and we are like a lot of Western people assume that Indians cannot sell self-organize Yeah, they're the people who make the code and we have to give them instructions and then I'll do it But I believe if you use agile and you bring more authority and power to Indian teams People will really you know, they will grow. They will take more responsibility and they will work You know using their brains to bring more value to your projects So I think the self-organization is one of the keys to make distributed teams work better Yeah, and you have a lot of different models in that think if you if you look at Scrum if you work with Scrum I think product owner on shore and then the full team Self-organized in India is one of the easiest way or the best ways to organize and if you have everything Distributed so you have teams with split between three locations. It's a lot harder to make that team self-organized Another thing I believe is that the Scrum master is really the glue in any collaboration Because the Scrum master can actually recognize what's going on in a collaboration on shore off shore They can find okay Well, if the client or the product owner is not communicating requirements well He could start talking to the product owner to find that that's actually in strong That's what a strong master is supposed to do But if it's a remote team, I think his role is even more important He can train his people to communicate better if he recognizes that the communication between the two sides is not working well In our company one of the rules that we have added to this is the process manager And that person is actually somebody who is outside the team So she's not really in the details of a project But she's only responsible for the collaboration between a client and the remote teams And she's looking at things so every week. She does a Skype call with the client or the product owner and sees now How is the collaboration going? She even has a metric on a scale of one to ten like this week What do you think about the collaboration on a scale of one to ten? It's a very easy metric, but it keeps your finger on the pulse So you see what's going on and if one week it's an eight and then it's a five You know, you have to change something another thing that I see like the number one thing remote teams complain about is My product owner is not available And I think the issue there is that product owners are often the most busy people in a company So they run around they have to talk to clients or stakeholders And they don't have the time to spend with their remote teams Whereas if you're remote you can't just you know in scrumps as a key co-locate everyone So if I'm as a developer during the sprint, I've got a question I can just turn around and I walk to my product owner and ask for clarification Now in a remote setting you want to simulate that at least so that if as a developer I have a question I can't get the answer within a reasonable amount of time So I don't get stuck for two days and then get blamed for my delay So I think we need to get engaged product owners that also have a lot of time And one of the things that I see in a lot of companies work is to have a proxy product owner It's you know, if you look at pure scrum then people would say it's not allowed But I think it helps a lot because if the proxy product so that would be a sort of Secondary product owner in the remote team who gets authority from the product owner to make decisions So if this developer has a question He can actually go to that person and in 90% of the cases he should be able to say okay This is the explanation and that requires trust between the product owner and the proxy product owner It takes time, but if you have that role solidly, then I think this collaboration is going to work a lot better some tools that I have used one is scaling up and this is actually a Method that is not agile as far as I think it's agile, but it's not spoken about on conferences like this It's it's actually before it was called the Rockefeller habits, and this is more to help companies grow It's written by an American guy Vern Arnish and the logic is you've got a once one-page strategic plan Now this has this is basically a complete overview of your company's road map So you have your core values your your mission your vision on this site And then it goes to three to five years plans one-year plans quarterly weekly and daily So this is a blueprint and you can use this also on the business unit or department level or enterprise level and Linked to this you have a communication rhythm of yearly quarterly monthly weekly and daily meetings and the Weekly rhythm is actually similar to agile So you have you work in weekly sprints you've got your daily stand-up with the management team and It has helped me a lot to create alignment among my different locations Yeah, that's a one-page strategic plan another tool that I have developed is the distributed team campus now The way to use this is on the this works on the team level So if you have a team that is struggling with collaborating you can use this to Streamline them and to have you know action plans to improve what goes wrong So there are eight building blocks and each of those blocks is an important element in working distributed So you could actually put the teams in one room give them a lot of sticking those put this on the wall And then do a workshop around this So for example, you can have the team discuss, okay What kind of cultural things do like intercultural issues? Do we have that this dropped our work and what kind of actions do we plan to circumvent them or to work around them? Now what kind of responsibilities do we put on onshore versus offshore now? We have the product owner far away what challenges does that bring and how can we improve it? Maybe we can add a proxy product on it. What what kind of tools do we use for the knowledge transfer? How do we make sure that everybody understands the product vision the roadmap etc? So you can map that all out if you're interested. I got a PDF with instructions on how to do this So I can send that to you another thing I developed is a culture canvas and The way this works is you've got some perspectives below here So you if I'm if I'm a Dutch and I'm working with an Indian team I will fill this about my Indian team and they will do this about me So for example if I'm Dutch and I reflect on the collaboration with my Indian colleagues I will say okay productivity is one of the perspectives So I expect my people and my team to be proactive and in my experience working. This is just an example It's not true in my experience working with Indian people I found that they are not proactive enough So I would like them to open up a bit more so they can share their smart ideas and we improve our team and our product Yeah, so I'll stick this and then I might say okay Some of my colleagues in Holland are actually saying okay the quality the quality of the code is not good enough So people tend to make codes and they just give it and say I'm ready. Nobody tests his work. That doesn't happen in India but I might say that yeah and Then as an Indian as the Indian team, I'll do the same about the Dutch So maybe again They will say okay this guy is very nice But he's too open sometimes and we get insulted and this kind of demotivates the team So the team spirit is not good enough stuff like that And then when you have those two perspectives You can make a top five of issues that you recognize which disrupt the teamwork and then you know come with actions on how to go about solving them So it's a very simple tool But I think this creates clarity or awareness about the cultural differences and how this Influenced the work because in a lot of teams I see Everybody agrees. Okay. There are cultural differences, but nobody really does anything about it That cultural training maybe but I'm not sure if that brings you anywhere because I think it's all about action You need to start doing some stuff So as a wrap up Create an agile culture because I really believe agile helps distributed work Traditional models don't work agile creates a spirit of improvement and this makes it much easier to make such distributed teams work Try to get some empathic scrum masters because I think empathy is key You want to have ideally you want to have women in that role? I believe that's my personal perspective You don't want to have a Completely introverted data oriented guy who prefers talking to his PC instead of people So I think that helps you want to have engaged product owners who have time to really answer the important questions of your teams And you want to keep the monkey where it belongs So if somebody has a monkey or problem on his shoulder, you want them to fix it Instead of saying okay, please take my monkey and you fix this for me. I Wrote six books about this topic. So if you're interested you could download them here It's on my Indonesian website because I started an agile transformation and training company in Indonesia So it's a keeper that go ad and then ebooks I will the share the slides will be there so you can find as easily and these are my contacts So if you want to get in touch or get if you want I can send you the PDF with the distributed team canvas and the slides Just drop me an email. I think we have some Do we have well for T2 so we have maybe 10 minutes to Do some Q&A, but I think it's lunchtime So if you want to go out for lunch just go and if you want to ask some questions, feel free And thanks for this thing. Are there any questions? Thanks No questions, then yeah Maybe let's take it off because everybody's leaving We'll do it in the lunch break We have time. Yeah, no, we're actually out of time, but it's okay since it is a lunch break We can okay, let's try Hi, there's a little here. I'm from A&Z Bank, right? So we have a technology office here in India, Bangalore So one of the challenges is we sort of I mean Ajayan is not new to the bank so we've been following these practices for a while, but we sort of Looking at establishing something for a particular department and so currently this team is spread across different, you know, Australia Even in Australia, we have Sydney Melbourne and we have Manila people in Manila Okay, so how do you create this so this team is coming together for the first time, right? So how do you create that feeling of single team and you know if he's and these teams are Coming from different organizations as well. So we have vendors, you know Some of these people sitting in Sydney or from a different organization. So we sing the bank and you know, we have Some parts of HDLC for instance testing is done by a different vendor here in Bangalore So so they are they come from different organizations, but they're all, you know, sort of trying to do achieve a common goal Right. So how do you create that feeling of you know, one team and we are in this, you know, together I think especially if you have like different locations within your organization and then also have third-party vendors. It's very complicated Because people, you know, ideally they identify with the company they work for and not necessarily with the company that, you know, hires them to do the work So but I think it like tool like this distributed team canvas can be a good start so that at least you have the people who work in one team Or maybe two or three teams work on something like this to identify the challenges and speak about it Because in the end I think it's all about getting getting some money top five or top ten issues that you faced and then agreeing Okay, these are the ten things we're going to do in the next quarter to improve on that Right. Instead of just saying it doesn't work or it's very complicated. So you need to and then budgets to get people together help I heard some other speakers say okay just get them in an airplane and it will work and that's true But what I have also found is it works like the week that you spend together it's all fine and then you go back and it's back to zero So I think you need to try and make it a habit of having good video conferencing stuff and playing with retrospectives for example That's also a good if you do retrospectives while with the whole team and actually in theory every two weeks you'll have an improvement point And from there you can improve because both sides client and vendor will have the same same challenges So feel the same. I hope that out. Thanks. I'll try that