 announcement from the organizers. Right now in Esquire, we also have the Lightning Talks starting. Of course, it's competing with this session, so I'm sure you don't wanna go anywhere, but if that's what you wanna go for, Lightning Talks starting now as well at 3.30. So welcome everyone. My name is Tarang Bakshi. I work for ThoughtWorks out of the New York office. I'm a business analyst, project manager. I've been with ThoughtWorks for a while, about seven years or so. So that's the extent of my experience with distributed agile as well, because ThoughtWorks has been doing it forever for about 12 years at least. So yeah, that's me. And I'm Siddharth, I've been a programmer, I've been working on distributed development projects in ThoughtWorks. And even before, for about eight to nine years now. Okay. So we'll be able to talk about just some practical tips that we've sort of learned over the years of doing distributed agile and how to set these projects up for success. So what we're gonna look at is a few different stages. And in fact, starting all the way from you, before you're starting out on a distributed project, we'll start with looking at what should you even consider to sort of qualify whether that sort of project is, makes sense to do in a distributed way, particularly in an offshore scenario. So that's where we'll start. We'll move on to, once you've decided that yes, it makes sense, this project should be done distributed offshore. Then kicking off the project also called an inception. What are some of the things we've learned things to consider when kicking off such a project? What are some of the things to think about mistakes to avoid maybe when setting up the delivery model for such projects once you're done with that kick off and you've got some information from the inception. And in the early days of executing delivery on such a project, again, some things we've learned, some things to watch out for. And very briefly we'll touch on just some thoughts and ideas for a steady state. But really it's about the stages leading up to that, because that's where we find some of the biggest things to do to consider, things to work on, things where things would go wrong. If you haven't thought about many aspects of this. In this room have distributed projects, a big majority. And how many of you have been doing it for years? Two, three, four years? Okay, so lots of you. So hopefully some of the insights we share, you would have noticed it yourself. But from an experience, we feel like there are small, subtle things that sometimes get missed out and they make a huge difference. So that's our attempt with this talk. And just to make things simple, we'll keep talking about a lot of different things. So the scenario to have in your head is that, let's just imagine there's a project that you want to get started. It's meant to be distributed between development teams in India and the US, and there will be active development in both locations. So that's the sort of scenario that most of our points will sort of apply to. But of course it could just apply in lots of other variations. You could have more than two locations, you could have a primarily offshore team with just some support functions on shore. But just keep that scenario in mind. Okay, so let's get started with qualifying the fitment. So I've been on a few projects where one project in particular can give an example. I walked in to the customer location on site. The project had been going on for about two or three months. And I happened to sit down with the head of product who was pretty much behind the vision for the product that we were building was largely driving our requirements. And I made a suggestion that, hey, we have some business analysts in our Pune office who'd love to catch up with you, understand some context on what we're building, these features that you want coming up next. We'd love some input directly from you. The response was, I don't think I need to talk to anyone sitting offshore. I'd rather talk to you while you're here. Offshore is a decision that IT has made, I have nothing to do with it. And also don't ask me to get on calls in the morning or late nights. I'm not willing to do that. So there have been a few incidents like that, and this made me think, man, I wish I was involved in when this project was being sold to make sure that some of the expectations were set right. Because one of the questions that we really, there are a few different questions that we're asking there. One is what's the driver, why are you going offshore? Why are you going distributed? What's driving it? Of course, the obvious answer in many cases is cost, right? People are going offshore to India, Brazil, all of these locations. Largely, primarily for cost, it's not unusual. But at ThoughtWorks, that's something often would be a red flag for us. If we were having a conversation and the desire to go offshore was primarily or only driven by cost, that would be a red flag for us. Because there are, again, the risks that come with that. One risk being that if it's just a cost play, then it could mean that potentially lower value work is going to come to the offshore team. Potentially, it could mean that there isn't a lot of buying about the talent that ThoughtWorks is bringing to the table. It's really hourly rates, okay, this hourly rate is a fraction of that hourly rate, and that's where we're going. So ideally, we're looking for some other reasons. We're looking for, okay, you want to go offshore or you want to distribute for scale. Okay, you need to ramp up, you need to get a complex product out really quickly, you need to scale. Great, we have lots of locations offshore that can help with that. Or maybe you're looking for specific skill sets or talents. Maybe some specialist experience with mobile applications, with high Hadoop, some of those. So those are some of the reasons that we are looking for. So we do vet for what's the driver? Why are you choosing to distribute or go offshore? And if the driver isn't, if it doesn't feel quite right, the answer isn't always to say, hey, we don't want to work with you. But it's to say, okay, let's spend some time with the clients, stakeholders initially, to set the expectations, right? To get them to understand that they'll have to think about things differently. Invest not in terms of money, but in terms of effort and time from their side differently. So the other one is, is there business buying? That's the example I gave you, right? Is it just IT that's bought in? The IT organization that has bought in and said, yeah, we're going to go to distribute it. If product has, no one has had a conversation with product or with business saying, what does going distributed mean for you? What does it mean in terms of how you will interact with people? What might it mean in terms of stretch into early morning calls, late evening calls? If those conversations have not happened, again, it will be a red flag for us because it will mean that likely we will hit into problems later. Because if the default model is to have on-site proxies for an offshore team, then again, that's a model that we find can very easily fail. It's a riskier model. We would much rather have all the key stakeholders directly having conversations with our teams or development teams sitting wherever they are. Whether they're sitting in Brazil or India or anywhere else. And the third thing we look for in these cases, are there big unknowns? Is the product vision, for example, extremely ambiguous? Is there a lot of discovery to be done? Is there some big chunks that need to have some validated learning to be done quickly in those sort of cases? Especially, or if there's technical, a lot of technical risk, a lot of unknowns around interfaces or around technical risk. We'll ask the question, does it really make sense to start with offshore or distributed on day one? Maybe we should look at, can we start with a small co-located team that can get some of the unknowns uncovered pretty quickly? And then as part of that exercise, we will also look for ways to distribute this effort to multiple locations. But let's not start assuming that from day one, this can work offshore. Because typically, again, it will mean that some of those goals or objectives won't be met. So let's talk about the next phase of this process. When you're trying to kick off the project, if you're trying to understand what the project is about, what the goal is, and so on. We typically call this the inception stage. But think of it as the first few weeks when you're trying to understand broadly what the team's supposed to do. So, and typically, you do that in a co-located fashion with the client stakeholders, and from our experience, it's really important that this team who goes and meets the client stakeholders to understand the project broadly needs to have cross-functional representation from all the locations, from both locations in this particular scenario. So it's important that you have a business analyst as well as BEAs, as well as devs, as well as QAs from both locations. An anti-pattern that we've seen sometimes is that let's get the BEAs from offshore and the architect or the senior developers from offshore, and that's enough to cover out the initial design and so on. But what that creates is a big gap in understanding and buying from the team on the other side. And when I talk of that, what it means is that you have a team of five, six people coming from different regions, even if they are from the same organization, they've been working in different offices, different regions, so it's possible that they've never met each other, they've never interacted with each other. And so it's really important that that team gets together a few days before, ideally one or two days before the kickoff with the clients is starting. But at least get together one evening before you meet up informally, get to know each other a little bit because otherwise it's very difficult to function as one unified team on the first few days of that inception workshops. So my most interesting experience for me on this one was I landed up at a client site on a Monday morning at 9 AM. And there were four other people who had come in to join me. We were going to run this inception. The kickoff was at 10 in the morning. And there were people from three different, three other continents. It just so happened that availability meant that there were four of us, people from different four different continents meeting up for the first time. We never worked with each other, we never knew each other. And we were going, we were involved with planning the inception activities, but we had not met face to face. So at 10 AM here, we were going to do a kickoff with the client, try and wow them and impress them, try and run some visioning sessions with them, and it was a challenge. I mean, if we didn't even know the people that are part of our organization and we were working with, it was always going to be harder to make it look slick, to make it look, to make it actually work smoothly. So one of the things we do now is make sure that the team can be together one or two days, even one day in advance, or at least a half day in advance before there is any interfacing with the actual client stakeholders or business stakeholders on day one. So the other aspect for both of us who've primarily been part of offshore teams during our career, it's very important for the offshore team members to make that additional effort to build customer, build confidence and comfort with the customer team. And this means simple things like people from the offshore team taking lead in driving some of the sessions in facilitating some of the exercises and so on. And while people from the on-site team who are likely to be more co-located with the customers going forward on the project anyways, they take a bit of a backseat and allow the people from offshore to drive. And this creates, again, some amount of confidence, amount of comfort and familiarity, which really helps when the project actually gets kicked off and we are back in India and interacting remotely. So this initial time spent in front and center of the room is really critical. So we've qualified the project, it looks like it's a good one. We should go distributed, we've kicked it off. We've understood enough about the vision, about the architecture, the requirements, and now we need to set up delivery. So again, so what are some things to think about? This one may seem obvious, we talked about it in the inception team, but the clear lesson for us here is that every location that is involved in the development needs to have a cross-functional team. We've seen it at many client organizations where they try to do distributed with the QA team, a test team sitting in one location, some developers sitting somewhere else, an architect sitting somewhere else, and a project manager at the customer location. And that's a big dysfunction for us. So every distributed project where there is going to be active development in multiple locations, we try to make sure there's cross-functional roles, including user experience designers if needed, but we'll try and make sure that there is no specialist role that only exists in one location. The other thing to think about, and this one is interesting, we've learned this lesson the hard way, it's balance of power. What we mean by this is that we do insist that every location has an equal role in any decision-making that happens about the project. There is an obvious, easy, convenient thing. Hey, I've got four or five people sitting in my office as a client. I've got developers, I've got BAs, I've got QAs. We need to make lots of decisions about this project, we need to move things fast. The convenient thing is, yeah, let's talk while we're all sitting in one room, make a decision and convey that to the offshore teams. Absolute recipe for disaster, we've even seen that with our own teams, where if you've not very clearly established that the people on-shore, at client-side and offshore, share responsibilities, it very quickly becomes a case where the folks offshore are story monkeys, have got development tasks that they execute, but have very little say in design and architecture. User experience is handed over to them to simply implement. So this is something that in the last couple of years, at least we've become very sensitive about and making sure that with our own on-shore teams as well as client folks, we very clearly said, any decision-making that needs to happen needs to be collaborative, needs to involve all locations, including offshore locations. Yes, there is a trade-off, it means that decision-making cycles for a lot of things will become much longer, 24-hour plus cycles for something that would otherwise have taken an hour in a meeting room, but that is the trade-off that comes with going distributed, there is no way out of that. If you need to have motivated teams delivering offshore, there has to be this balance of power. Of course, we believe that that makes for better decisions as well in most cases because people at the offshore team have different and unique insights sometimes on the code base or on the product. So an example I actually want to share on that one is, this was a learning for me as well. So I was on a team as a business analyst offshore. And I happened, I moved on-shore because there was a role needed there to support the offshore delivery team. And I went on-shore and was like, yeah, okay, all the customers, stakeholders are here, all the people who do the requirements are here. So my daily cycle was sit with all the business and product folks, understand the requirements on new features, end of the day, get on a phone call or type up a long email as a brain dump. And then the BAs offshore would write up user stories based on that. They would come back with questions and I would forward the questions to the product and business folks. And very quickly, it became impossible to work in that way. I just didn't realize what impact that was that meant for the teams offshore. So when we had to move, we ended up moving to a model where my role I looked at is it's a facilitator on-shore, the requirement conversations from the absolute beginning were being driven from offshore. I just had to make sure that the stakeholders on the customer side, if they needed some prodding, if they needed some follow-ups, I was there to do that. But I didn't know enough about the big picture requirements to even provide a brain dump. So I had to move out of that role. And this something, it's come as a learning that we need to do that on-shore roles don't necessarily mean that those are the ones with all the meaty information and offshore has got all the scribing and low level work to do. So how does the offshore team actually communicate with the stakeholders? What does it look like? Yeah, we had made two windows that allowed for that. And we'll talk about that as we go. The other thing that's really important while trying to set up a distributed development team is to figure out how to split up work, what kind of work should be done in one location versus the other. And here our strong recommendation is to ensure that work is split vertically, meaning you carve out a set of features and make the offshore team the owners for those set of features, carve out a different set of features and make the onsite team the owners for those. Anti-patterns that I'm sure a lot of you guys may have seen or experienced is all the UI work will be done in one city and all the services will be written in another city or all the development work will be done in one city and testing work will be done in another city. That in our experience doesn't work. And connecting it to the earlier point of cross-functional role, so it's really important for teams to be able to own features end to end, both in terms of all stacks of the architecture, as many stacks of the architecture as possible, but also in terms of analysis to requirement, understanding and analysis to deployment. So you keep it such that every team is fully set up to be able to do any of these stages themselves. And related to that is that it's important that the split of features is done in a fashion where features that are connected or correlated in some fashion are grouped together and handed over to each of these teams. And this I think is really important because it usually features that are correlated are also correlated inside the code base, maybe in the sense that they'll use similar classes and methods, same classes and methods. And it's important to keep that in mind while you are making these decisions because one of the most difficult things in working distributed is if you have day-to-day code level dependencies on a daily basis, if you're working on the same set of classes or methods that a team on the other side is also working on, then it can cause a lot of confusion, it can cause a lot of extra communication overhead, and so on. So it's important to split up to logically pick up features such that different areas of the code basis will automatically be owned by different parts of the two teams. Sorry? Yeah, module-wise split up is a separate, you know, we can talk about it more offline, but here what I'm suggesting is end-to-end, you know, end-to-end split up, not just some components owned by some teams. There is an obvious risk, right? You're gonna say if you split up by features that are closely related, there is a risk of getting into a state where there are silos, where there is not enough knowledge about one set of things, one set of features in your code base in other location. So we are always conscious of this risk, but we find that the trade-off between the chaos and confusion of day-to-day dependencies versus, you know, the some risk of some knowledge we're getting into silos, we find that we tend to go towards actually splitting that up and finding ways to consciously have knowledge shared between among those features, either by swapping people across teams or finding other ways to do that. Do you think vertical slices would kind of take care of this? Yeah, I think the idea is also about the related features that you want to group together. You could, one, potentially, you could just say here are vertical slices and we can arbitrarily assign those or happy teams, pick them up from a common backlog. What we're saying is no, there is some active effort to say that these groups of things are actually related to each other. They'll touch in all of the same underlying code. So maybe it's best that one location holds it rather than arbitrarily dividing it. I mean, the classic anti-pattern that I've seen, you know, seen just too many times is that the team works of a shared backlog, which is fine, but it's almost random that if team A finishes their story today, they'll pick up whatever is the next most important story in that common backlog right now. Regardless of which feature it belongs to, which area of code base it belongs to. And team B, when it finishes their story on the next day, they will pick up another story which maybe is related to that story that the team A just picked up. And so that just is too confusing, too costly in terms of the communication overhead that it creates. And while we talk about this separation of ownership of features and end-to-end ownership of features, we're still, you know, just to clarify, we're still talking of very, very frequent integrations. We're still talking about one single continuous integration pipeline, one single continuous deployment pipeline. So it's not as if the intent is for the two teams to work independently at all. So continuously you are checking every check-in works against the combined code base and all the integration tests work against the combined code base at all times. Yeah, we'll talk about that, yes. So another one, almost it might sound like it's a counterpoint, but it's not, when it comes to things like metrics, when it comes to things like managing the teams, one of the things we do focus on is making sure it's treated as one team. We've been badly burned by going down the path of, oh, onshore velocity is four points per week per pair, but offshore is two points per pair per week. What is going on? Why is offshore half as productive? I mean, aside from the point that that sort of use of velocity itself is dysfunctional, just trying to do that and separating those and treating them as, oh, I have an onshore team and an offshore team. I think we've found that to be extremely risky and a really bad idea. So we will try to make sure it's considered by client stakeholders, by our own teams as a single unified team. We're not trying to create divisions other than for purely practical reasons like dividing our features and things like that. Distributed, then it will obviously happen, right? The data will itself be collected. But you can get some, especially the features are distributed over the data. Yeah, the data will, may tell you something like that, but there's no reason to actually track it that way. It's a team velocity. It's a team planning effort. It's a team output that we're doing. So while the temptation may be there, what we're saying is that resist the temptation to try and look at the data as, oh, this is my velocity in Chennai. This is my velocity in New York and so on. We'll talk about, actually, we might not have time to talk about it, but offline we can do that. Okay, and the next thing I wanna talk about is, so now we've set this delivery up, right? We've now gotten into active delivery, our sprints or iterations have begun. So what some of the things to think about and plan for in the early days? Now, rotations is the most obvious one, right? There was stuff when there were articles 10 years ago about distributed agile. The first thing in there was about rotations of people, but even today we find that there are a couple of things. One is rotations only seem to happen in one direction, which is from offshore, you have people traveling to customer locations. That's one. And the other is that rotations tend to be, oh, I made a two-week trip to the customer side, and that's why we're doing rotations. In our world, rotations would mean working for a reasonable period of time in, on the other location. So six weeks, eight weeks, two months, three months, and we will try to do it in both directions. So we'll plan on that if that needs to be some budgeting thing that needs to be done to make sure that our developers from, from onshore, our VA's, our project manager can spend a few weeks in our offshore locations. So whatever it takes, the visas, things that needs to happen, the monetary allocation, we'll try and make sure that those rotations are planned in both directions. But the keyword there is working from, getting the experience of actually working from the other location is critical. It's one thing to meet people face to face and conduct discussions and sessions and so on, but it's completely another thing to, to actually work on a day-to-day basis from the other location. So that gives, gives both teams a lot of insights. I think the, that goes a big way towards that empathy and the trust that, that needs to be built across those locations and it doesn't matter whether in the ThoughtWorks world, there's a good, sometimes we client developers, client VA's and so on. So we could do a core source model. We'll try and get everybody over if we can, doesn't matter whether they're from ThoughtWorks or from the client organization. This one again, it seems obvious, but it's shocking how frequently we have distributed projects start off where the classic conference call, you would have seen the recent video that became very popular, but somehow, even though this idea has been around for probably a couple of decades, but by default using video for all distributed communication, we'll spend a lot of effort making sure that's the habit from day one and the default and whether that's supplemented with screen sharing and document sharing, but we'll get into that default habit of, hey, everything needs to be, we need to be able to see each other and we need to be able to look at the same thing that we're working on together. We're just not going to do conference calls alone. So on most tables, you'll find, because this is a topic that we can't probably spend a lot of time on just different synchronous and asynchronous communication options, most tables you'll find there are some bunch of handouts. So that's, you can take those away. There are some more details there about hardware, software, ways we've used things for distributed communication. Yeah, but this one we can't stress on enough. These days, in my view, these tools, the bandwidth on both location, has improved so much that if you use video and supplementary tools like screen sharing and collaborative document editing tools and so on, well, with good hardware as well, then it can very closely replicate being there in the other location. And for those in the back, if you don't have a handle, we have a few extra here. So if there are any left at the table at the end of the session, we can give them to you as well as the others. Okay. So the idea that this is still one team, that is, it just happens that a few of the members are in one city and the few are in another, is important to keep in mind. And when you think of that, it's important for both the teams to try and get to know people on the other side as people, as human beings. And there are just some small things that you can do in the early days that help towards that. So on one of our projects, our project manager in UK asked us to send pictures of everyone who was on the offshore team. And he put them up on walls at the client office with names and roles and so on. And he got feedback from clients saying, oh, I've been talking to Chirag for the last few days, but now that I see his face, it just feels better. I have seen other teams do other informal things like share their hobbies in a mail thread or share something like that. But those sort of informal communication between these two teams really helps. And I've used on some teams tools like Yammer or Skype chat rooms or IRC chat and stuff like that to of course talk about what's going on on a day-to-day basis on the project. But when you have tools like that, which is not email, which is not formal, then you can do other interesting things. You can wish people on their birthdays. You can share jokes. You can pull people's leg and so on, which connect the people on both sides on a human basis, which helps in, when there are tougher times, it helps in that. And this can be a little tricky, right? If you're in the scenario we talked about, it's a US-India distribution. We're barely getting one, one and a half hours of overlap time. So the obvious urge is that, let's just keep it to business if you're talking for an hour and a half. Let's just do that. But one of our mantras there is make time for banter, make time for that informal. It doesn't matter if there's something about the project that has to be done over email later. But in the early days, that sort of getting to know people and getting to know them as human beings is critical to the success of the project. And the other thing is that if you are one of the folks on the offshore team who's got initially the time to the face-to-face time with people on the other team, then you ought to take that additional responsibility to get your other team members to get to know these people better. So it's about sharing anecdotes about your trip that you made over there and what did that person say? What is that person interested in? Just connect people up. You have that additional responsibility if you have met them face-to-face. This is similar to the ideas that we've talked earlier about balance of power and having that sense of shared ownership between the two teams. But oftentimes we've seen teams default to, okay, I'm at onsite and here are five clients, stakeholders who are sitting in the same room. So let me drive every single meeting, every single showcase, I'm the best person to drive it. And while that is true from a practical point of view, it is really important for the offshore team members to drive some or most of these meetings directly from offshore. And again, with the tools and hardware that is available now, it isn't that big a difference in experience. So again, the idea is that the offshore team members should drive these communication and the on-shore team members should be there in case of communication, in case of a hardware failure. So if the network goes down or something like that, then the person can rescue that situation by telling some jokes or maybe by continuing through that presentation later on. So we use this for showcases for sure. We'll have most showcases to client folks made driven by offshore planning meetings, retrospectives, all of these things that we'll try to make sure that the location that is not sitting next to the customer has that opportunity to put that front-face forward. The other aspects, especially as teams, distributed teams in particular grow larger, when you talk here of 20, 30 people in all across two locations. Regardless of which other tools, at least in my experience that you use for communication, emails will still be a big chunk of, it will still be the big medium in which people will ask questions or ask for opinions or circulate decisions and so on. And there it's important that the team approaches email communication in a structured manner. So I've been in situations where we haven't paid attention to email that's coming on from the other side enough. And suddenly it happens that there was something important that somebody had asked, last night we didn't look at it the whole day today. And the next opportunity we'll get to look at is 36 hours later or 48 hours later as compared to when they had asked it. And those sort of things can very quickly reduce trust, reduce confidence and so on. So we've just to, and so that's it's important to approach it in a very structured manner. A couple of things that have worked for us is on projects we've taken, we've almost set time aside, maybe the first 30 minutes, even before the morning stand up of a team, we spend the time for everyone in the team to read and respond to their emails, for example. On another team, Tarang and I were on recently, we had a couple of people take over the ownership of being email shepherds, which basically means that they'll keep track of, or these were three questions that came through today in the technology choices area. These three questions were around QA processes or tools area. Let's ensure that somebody in the team has signed up to look at it and respond to it within a day or two, so that it doesn't get lost. And this may seem like a trivial thing, right? Yeah, everyone manages their email whether you're distributed or not, but at least we found that just that simple thing of acknowledgement that goes back, yes, we've seen it, we're working on it, or hey, here is the response. I think that makes a big difference to that trust level that you're going to have. So we do as project managers, both of us, we do pay a lot of attention to it. Sometimes our team members will feel like we're being a little anal about it, but we're just not going to underestimate the impact of that medium of communication, regardless of how many video conversations we're going to have. And coming back to a question that one of you guys asked earlier about, there are, when you have a distributed team, you will have to tweak your practices, whether it's stand-ups or retrospectives or planning meetings, a little bit to account for the fact that you have people in both locations. So for example, in retrospectives, it would mean using web-based tools that allow people to look at points being put up by both sides, having video on both sides, having facilitators on both sides who've earlier met up and synced up notes about what structure is going to be followed and so on. But even other things, like it's important for you to try and try and find avenues to exchange feedback between members of the two teams, of the two distributed teams, to broadly seek feedback from the other side of the world about how things are going and so on. So it's important to keep that in mind that those small tweaks are important. All right, so we've gotten through the early days, we've done all the right things. Now the project and the teams have moved to a steady state mode. So we're not going to spend a lot of time on this, but just some quick things to keep in mind. We find that rotations often start to disappear. It's the first few weeks of the project. There'll be some travel happening, but they don't happen consistently throughout. So again, something to keep in mind, just make sure that the rotations happen throughout that life cycle of the project. Another important thing is to celebrate small successes together, whether it's small milestones that have been reached or whether it's just any kind of positive thing that has happened, just celebrating that together over a long period of time, again, doing that by default, using some of the channels or tools that we have mentioned in the handout. We found that again to be critical for continued success. So again, anything else? So just recently a project that I was on, it was a team distributed across six cities. And we did our, we had our Go Live celebration. Go Live basically occurred. It was a big public Go Live, it was a big event. And when that happened, we were all on a video call for three or four hours to ensure that everything goes fine. And at the end of those four hours, when we knew that it was, you know, it was finally live, we had people in Istanbul and in Brussels where the client stakeholders were, they actually had champagne bottles ready, arranged to celebrate. And they opened up the bottles on video, poured glasses and, you know, cheers to everyone on calls. And just those small things, you know, cutting birthday cakes, you know, while the camera is on on the other side, just those small things make it, make it, you know, one team. And finally, maybe somewhat controversial for some folks here, but while you're doing that distributed project, keep looking for opportunities to not have to distribute it. Distribution is hard. It's a lot of work. It comes with lots of trade-offs. So if there are ways in which, you know, the work can be largely moved to one location or a team can be co-located. Don't lose sight of the fact that, you know, you can still look for opportunities to do that. You don't have to do that model for forever. And in our experience, you know, on most project after about six months, nine months, there is usually a quite a clear opportunity to try and reduce the distribution. If you have three locations, it's possible to do it in two locations. If you have two, it's possible to do it in one location. So it does ease things considerably, whenever you can do it, depends on the context. Let's say with the disability, we're sitting here, so how would you accommodate the demo person, the demo person? So technically, you might put the time zone You are facing a table, right? So you don't have any thoughts on how... Yes, I'll repeat the question now. So just to make sure I understood it, right? When there's a distributed team spread across, particularly, you know, lots of time zone difference between the two, how do you manage demos? Because if you're waiting for the other side to be up, you could lose some hours until you're able to do a demo. Is that the question? Let's say the last day, right? So it's not over for the other team, right? So you need to put up, assume that you're putting up a sprint demo on every sprint completion, right? That's why we're looking at it as a monolithic thing that we do a sprint demo and the entire team presents everything all at once. You know, one, we'll look to just present things as they are ready. So it doesn't matter where they got ready for them, but of course, if you're presenting to the client stakeholders who need to provide feedback, then yes, it will sometimes mean a 24 hour gap until we can get the right people. I mean, until the right stakeholders are there, the purpose of the demo isn't served, right? But the important thing is that when you're demoing, when you're showcasing, even if you're doing it formally, it's important for the offshore team to directly talk and present the features that they've worked on and for the on-shore team to directly talk about the features that they've... And... The day which, you know... Yeah, but the end of sprint is a notional thing, right? I mean, you can just decide that 8 a.m. US time is when the demos will be and whatever work has got done till that time on a Monday morning is what counts as a sprint on both sides. The skills or the expertise, you know, the distributed team could be on a model, which I've had a platform level, private level, and private level. So it's very hard to form a team, you know, which has these roles, because that's a practical problem. Do you have any thoughts? We usually solve that by rotation, by ensuring that a few people who have worked on those areas work from the other location for a few weeks or months. But we haven't experienced a lot of that, honestly. We haven't experienced that there is something that the people only in India can do and something that people only in the US can do. All right, questions? Any other? About the metrics, but where are there some metrics, some measurements apart from velocity and the internal retrospective that you came across during it? Specifically here. You know, in terms of how the distributed teams are doing? Do you have a meaning in agile? Yeah, so that's a whole different topic in some... You can share your experiences. That's very different from the, you know, we are focusing on what is unique when you're doing distributed agile, you know, in just doing, in running projects in an agile manner, there are, you know, you think, you look at measuring different things and projecting it differently, but that's a very different topic. Let's talk about it offline, but take questions on the topic. Or if the organizers give us 30 more minutes, we could talk about it. Yeah, in the back. Have you had situations where you had very, very distributed teams, like for example, England was taking US and in Europe and, you know, in the Pacific region? So that means you don't have any kind of, you know, common time at all. The Japanese celebration example we were talking about, there was Tokyo, there was Pune, Bangalore, Istanbul, Brussels and San Francisco. Okay, we're almost, we're actually out of time. So, but, you know, reality is that in those sort of cases, we can't get everyone together for everything. We will have to distribute the communication when possible. Is there any specific challenges in vitamin P 15? Why do you have to distribute it? Actually, there are going to be more important answers. So should we, because there's a 15 minute break now, so we could answer some questions. All right, thank you. Let's carry on the conversation in the copy. Thank you. Thanks.