 When I started working in Agile, around seven or eight years ago, then most of the books or most of the material which we had was around Agile, which was about the colloquial teams. But if you think about the services company or the way things work in India, most of the work is off-shored and what we need to do is working in distributed Agile. So as far as the material is concerned, there was very less material around it, so we had to struggle about it like what we need to do when we start working in distributed Agile. So basically what we started doing is we started experimenting and see like based on our common sense and pragmatism, how things work in distributed Agile. And then we started evolving certain patterns. So this conversation or session is all about those patterns or the practices which we generally face in our way of working when we are working as an outsourced vendor or working with multiple distributed teams. So this is basically the outcome of that experience. Yes. So basically the teams sitting in the distributed location, it can be like entire team is distributed. That means each and every member is in different location, different time zones. So that kind of stuff. But most of the common way of working is that your customer is at onsite location in US or somewhere and then you are working as a team over here. So basically we try to see like how Agile can work in that kind of situation and we evolve certain practices out of that. So as far as me is concerned, I am working as an Agile coach and director engineering at Global Logic Noida. I have around 16 years experience. I train in Agile-Agile testing, continuous delivery, specification by example, continuous inspection. Personally my hobbies are singing, counseling or self-help thinking. I am available on Twitter and I write a lot of blogs also on AgileBuddha.com where based on experience we write our stuff. So before we start talking about what can be different patterns, let's see like what are the failure points. So because what I have seen is that we started blaming the way of distributed way of working but actually there are basic problems in the way you are working right now. So first thing is that not actually doing a basic scrum in the first place. I mean let's forget about what are the kind of problems you are facing in distributed or not but you are not doing the basic scrum at all. For example, there is no retrospective, there are no planning meeting or you are not measuring the velocity in the study points. So basically in the first place itself if the scrum is not working then it is very difficult to define if the distributed scrum is not working or scrum is not working. Second thing is that inadequate tools and governance mechanism to make asynchronous communication successful. So in my experience what I have seen is when you are working in distributed locations then communication is the most important thing. If you are not having a good amount of communication and communication channels then basically you will be facing a lot of problems. So if there are no adequate tools or governance mechanism to make it happen, either a co-location or basically working in the real time using video conference and those kind of stuff that becomes very difficult. Then this is also a very, very important point, V versus they or vendor versus customer mindset. So even though you are working in a distributed fashion, customer thinks as a customer and basically the term is a vendor versus customer mindset. Again it's not like it happens only with the customer or vendor. It is a kind of general human phenomena when there is a lot of scope or gap in the communication then you start forming the V versus they kind of culture. Then unbalanced distribution of the work and ownership. So that also makes a lot of problems as far as distributed agile is concerned. So let's move to the distributed agile success factors. So you may say that fine, these are the failure factors. So if you reverse them then they can be success factors but that is not so. I mean there are more factors which I would like to touch base over here. So first and foremost thing is that I think the most, many of us, yeah basically the different time zones supporting is also, it cannot be a failure point, it can be termed as a challenge I would say. How you basically mitigate how to work in the different time zones, I'll be discussing that later. So distributed agile success factors. I hope many of us are programmers over here and many of us have read something about distributed programming. So one of the first principle in the distributed programming is don't distribute at all. So if you can avoid the distributed way of working that is the most, I mean that is the first thing you want to consider because as soon as you start thinking about distribution then basically it comes with a lot of problems or not problems, the challenges and basically the ROI which you will be getting later, it takes a little time to get that. So first and foremost before you consider any other thing, try to see like if you can avoid distribution at all or not. Then this is also important thing that when you are working in an environment of distribution then trust takes a toss and because of many reasons, because of the communication gap, so for example like let me take an example. So two developers are working in one location, one is working in the Netherlands and one is another is working in India. So now what happens is that this guy wants to talk to that person but the other guy on the Netherlands and is not able to take those messages because he wanted to focus on the work and he is not able to see the messages coming from the sky for example. So in that case the other person thinks this guy is starting avoiding me or he doesn't want to talk to me. So basically these kind of communication gaps starts making some kind of problems and having the trust problem and there are other factors also from the vendor versus the factors and those things that also create trust deficit. So trust is a very, very important thing if you want to really work in a distributed fashion. Courage to change and I think this is one of the important things which based on my experience because our projects really worked because we thought okay this thing is not working let's try to see like what are the other options and let's try to implement by tomorrow or by the next print and see how it works. If it doesn't work then we can change it further but in many projects I have seen that there is a lot of resistance to change. I mean even though they find they feel that for example like there is a product on or at the on site and he's not able to devote the time but they keep on cribbing then basically they don't do anything about that that problem and then sit on the problems. So instead of sitting on the problem it is very, very important that you think what can be done in this kind of situation and many of the things which I will be discussing later are based on our experiments based on the kind of situations we face and we try to make changes on top of that fine. And when you have the courage to change then that brings the innovation. So for example we started doing the distributed pay programming just because we were distributed in multiple continents and we thought that knowledge exchange is very important. We were able to do the pay programming locally but then we started thinking let's do the remote pay programming at the time and we started doing it. We started doing it even when like for example somebody is working from home then that guy can also still work in a distributed pay programming fashion. So basically when you see the need and you want to make the change and then you find some new ways to do the same thing. I cannot stress more and more about the communication. Communication is one of the biggest factor why distributed projects may fail. Because of the communication problems and because of the human touch you start losing the trust in other people and that starts creating the problems. So to avoid that what I've done is, yeah sure. So I mean because we are distributed what I've seen is that there is no one way of doing the communication. There are many ways to make sure that the bridge of the two humans is bridged somehow. So communication is what? Like I want to feel you as a person in front of me instead of somebody is there who is doing some kind of typing. I mean that human touch is very important. So what we, I mean first thing we did was like having some kind of colocation so people from the onsite keep on coming over here or we keep on going over there. So that way basically the human touch keep on there. And then basically what we also did was doing kind of video conversation or distributed programming. So that those things, so basically I think what I've seen is that colocation is important after two or three months because what happens is like for example you come to the onsite in India and you feel very one team and you can really see them, I mean touch with the other people in India. But what happens is that as you move to the distributed location after two or three months that emotional gap starts bracing up. I mean it is a normal human tendency. And then again that person remains yet another entity. So human touch is very important. So whatever way you can bridge that communication gap or bridge that human touch that I mean there are many ways to do it. So what I've done is that I have structured these patterns into two forms. One is structural patterns and another is implementation patterns. Structural patterns is like okay this is the kind of situation we have. In this situation how should we structure our team and what are the pros and cons on doing that, fine? This is the way, this is the kind of structural way of doing things. But then basically implementation is like for example now we are in a situation where there are two time zones we are working with the US team over there and here India team. In this kind of situation what are the things which we can do to keep ourselves better. So there are two things. So I would like to touch base both of those things over here. So these are structural patterns. So local control distributed team. So local control means that the product owner and the scrum master is on the onsite. There is some team in the distributed location as well. And then there are certain people in India. This situation happens when for example like you have, I mean you started doing the startup for example. You have certain front end developers and now what you want to do is you want to basically extend your team and with India and want to have some back end developers, fine? So this is the kind of situation where you want to have more people in your team, fine? So in this case, this is most useful when team size is small. For example, a team for its persons scrum team. Team members are peers, little or no mentorship required. So this is a very big problem. So the trust deficit starts happening. For example, there is a team in US who are having around 20 years experience. And then in India, you start having a team of two years experience. And then all the time, those people are teaching that team. Then I mean they will not be a huge trust deficit. And that thing is not going to work. It is very, very important when you start working in this kind of fashion that natural overlap of five to four to five core hours should be there in the time zones, fine? So it can happen, for example, if you're working with Australia or you're working with, for example, Europe, then you can do that. But if you start working in extreme times when it is not going to work, makes sense? Because when you're working in this kind of fashion, then basically you have to exchange the knowledge all the time. And that cannot happen if you don't have the core hours, fine? Yeah, I'm not saying it should happen like this. These are the situations which happen in the real time. For example, I start building a startup in US, fine? I have four developers with me who are all front end developers. I need back end developers and I want to outsource that in India, for example, fine? So in that case, I talk to a company which gives me four back end developers. And they start working with me. I gave the wrong example in US, I should say in Europe, for example. In Europe it works. So that way you have a scrum team which is working together to build one product. Yes, yes, you'll be having all the meetings in a distributed fashion, using Skype and Screenshare, and people do that. Yes, I mean depends, like whether the customer is a product owner and he has to be there for answering the questions and stuff like that, and he will be there. Yeah, I have a point here. Yeah, it will be, yeah, basically I would say that I will be coming to that. That there will be, there is a pattern for that as well, fine? I have a point, though we have a distributed team, we can work in such a way saying the number of features. If that can be split up so that the, for example, India and US, India can own up few features which they can run and they can own and they can take it up, that will be a very good thing for the scrum teams. I think you have a point, a very good point. But the thing is that in this situation, India team as a whole cannot work on their features because they are back end people. Front end people on the US side cannot work on to end feature because they are the front end people, so that is a kind of real situation. So I come to that, I mean you have a point, but that is also covered over there. You can say that there can be some kind of local facilitator in India. Yes, daily stand up, daily, I mean planning, demo, whatever you call and everything. Okay, so let's move on. So, then the other thing is that continuous communication channel open all the time between the team members. So that means you will be having a situation where people have the headset. They have the laptop and they can do the communication. There is a very good bandwidth and stuff like that. So basically you have a good communication mechanism to be in touch all the time, fine. Good tool support and frequent face to face contact between team members to maintain team identity. So if you are working as one team, I mean one team means one team, and you want to make sure that there is a good amount of trust between the team, then it is important that there is a kind of collocation. Some team members frequently go to other side and that every three or four months, so that way it really works, fine. So problems to watch out for. So one is non-peer developers or too large a team. So in case there is a huge amount of difference in terms of experience, then it's not going to work. It will be just deficit by default and it's not going to work. Limited face to face communication, and because of that remote team starts feeling detached from the way they are working. Limited natural overlap in working hours and because of that team members will get burned out unless they start moving their working hours, fine. So lack of good real time tools and security communication tools, I've already discussed that. Then this is the next pattern, which is remote functionality. And basically in this context also, actually in the earlier one, it was a kind of situation where they had both of the people like developers and testers as well. But this is a situation where there are people who have functional knowledge in some area and functional knowledge in another area and that they are working together. So in order to make it work, it is very important that there is a strong functional expertise and ownership in the remote geography. So it should not like they are not doing their own work and remote team. I mean on-site team has to teach them how they're going to work. Then discipline, scrum, implementation with artifacts available. So in case, for example, you have testing team in India and development team in US, then it is very important that the kind of communication or artifacts available globally, they are available in real time. So otherwise, if there is a lot of communication to and fro is happening, then this will create a problem. Problems to watch out for. Remote team members cannot attend full kickoff. At the respective team meetings, I mean, it's not going to work if you have the ceremonies, but basically the whole team is not attending that. And that creates a problem because, for example, I have a feature, I want to estimate it. And for estimating, I want to make sure that there is a feedback coming from the developers as well as from testers. Because both of these people will be having some kind of understanding about that feature and based on that, you can estimate it. So if people start estimating like this is their estimate and this is my testing estimate, that starts creating the problems. First of all, it creates a problem, the B versus D. Plus, second thing is that when both of these people sit together, then they give the inputs to each other, which is very important for the feature implementation. So it is very important that both these groups sit together and participate in the ceremonies. Any question on that? So what we did was we were having a local stand up in the morning for our team, and then we had a distributed stand up with the common team. So that, for example, there are certain things which we want to communicate to that team or they want to communicate to us, that can happen. But our day used to start in the early morning. So first of all, as far as stand up is concerned, it should be maximum 15 minutes, whatever it happens. So in the stand up, what you're talking about is like, this is where I am. And I'm stuck over here, I need more information. I need information from you, can you help me after the stand up please? Yes, yes, yes. I mean the stand up is just for the update and for the synchronization. And then after that, whatever things need to request a discussion, you take it offline. I will be telling you one of the pattern in the later cases. What we had was we created a common time window in both of the locations. In US as well as in India. So for example, in the evening, we had six to eight, we had a two hours common window in that no one can do the local meetings. I mean, for example, US people cannot have their own local meetings over there. That time is devoted for the whole, for the distributor team. Similarly here as well. So in case you need to communicate with any person, he will be available every day. If you don't do that, then basically you'll be having problems if this guy is not available because he's not there and that kind of stuff. Make sense? So as I said, like remote team will be missing the context and fail behind the on-source. And this is the pattern which I generally like and which one of the lady here mentioned also. Is that if you can have the future teams, which can work independently, fine? Why do you need the distribution? It happens. Many times people create the distributed teams just for the heck of it. Because we have certain people in US. Because we have certain people in India. Let's have the distributed way of communication, stuff like that. Many times I've seen that, that is not really required. You have certain people over there. You do the future development over there. We can have our own future team which will be developing the features over here. They can touch base on the integration points and that will work. You can avoid all the poor problems which comes with because of the distributed communication. You can avoid working in the late nights and stuff like that. Make sense? So this can happen when there is loose coupling in the features. If what happens is the one bug, if you have a one bug and that really caused the problems in the other feature and there's a tight coupling then it's not going to work. Make sense? If you need to have a lot of communication to and fro then again it's not going to work. But many times I've seen that it works. By default, people create distributed teams because we have certain people over there and over here. So we need to really see whether we really need distributed teams or not. Fine? Yeah, yes. Exactly. Yes, yeah, I mean they are the feature, independent feature teams. They have autonomy to develop their, I mean, there can be product owner over here who can define basically what needs to be done. But as far as implementation is concerned, that can be done independently by the future team. Okay? See, the thing is that you will be, I mean, by definition whenever you work in the multiple teams, you definitely define a kind of release planning. This is how we're going to work together, multiple teams. Fine? Then we will be creating the integration points so that you can work. And we will be integrating at this time. So basically that, I mean apart from working independently, it is important to have a kind of governance on top of that. Make sense? So that whatever planning is happening end to end, it's not like this guy is working in one island, another guy is working in another island. When they start integrating after six months, then nothing works, fine? So you have these teams have to make sure that end to end integration really happens frequently, make sense? So they can work on one vertical slice out of the, I mean, part of it is developed by one team, another part is developed by another team. But they have to integrate in one sprint, for example. If that integration is not happening, this creates a big, big troubles. Because people feel very happy in working in isolation in their own island. And when they start integrating after three months, I've seen people struggling for months just to integrate stuff. Yeah. See the continuous integration is, there are two parts of continuous integration. One is continuous integration within your team. Fine? So basically, whenever you push the code into Git repository, you start building, compiling, running the test cases for your component. And everything works, fine, very, very good. But who cares about the end to end integration? See, one of the point which Nareesh made yesterday is workflow test, fine? One is like you are doing your own component test, which works, fine? And in case there is trouble in some another code base, it will break and you'll find it. But what I'm trying to say is that at the end of the day, product order needs a end to end functionality working. It doesn't care that your component is working. So it is very important that that vertical slice where one team component, another team component, works together. And that integration happens in a continuous integration environment. Make sense? So that is very important. That's where people don't care on, I mean, people don't care and then they find a lot of troubles because of that. See, the whole governance model is just because of that. I mean, that's where I said beforehand that you need courage to take some certain steps. So I mean, I will tell you the example. I was working in a team where there was, I mean, there was one team which was creating the backbone of the whole entire architecture. And then there is one focus team working on the front end, for example. So now what happened, we had the same situation which you mentioned. Then we made a decision, okay, we are already done with this kind of stuff, backbone, and this is where we are. So let's divide the team. Let's move these three people to the front end team and start working, fine? So you have to take decisions based on what is happening right now instead of just, okay, this is a team which is there and it will continue to be there forever, makes sense? So with that, let me move to the implementation patterns and implementation patterns for multiple things. So there are distributed teams on two locations. Distributed teams on two locations with opposite time zones, fine? And third one is fully distributed teams. Fully distributed teams means you have people, I mean, each and every individual is working from their home in different time zones, seven to eight time zones, and how it works. Then distributed teams on multiple locations. So in this discussion, I will be focusing on the first two. I can base on the other two as well, but I don't have time to focus on those two. So let's start thinking about distributed team on the two locations, fine? This is how it looks like. So you have some people working in the UK, then there is some people working in India, then this is how it really looks like. So India team starts working from nine o'clock in the morning. They basically do the local stand-up at nine o'clock. Then after that, they do start developing their code, coding new functionality. Then, for example, 12 o'clock, there is a distributed stand-up, in which in case there are troubles, then we find out, okay, I need to touch base with this person or that person. We need to do the distributed programming with that guy or that guy. So that kind of decisions takes place. And then other things can also happen over there in this core hours. I'm talking about the yellow stuff, yellow time. That is the core hours where these people work together, okay? And in that, you can have all the things, distribute demos, distributed planning, whatever you name it. And then what happens is at that six o'clock in the evening, India team commits, and basically they continue, I mean, UK team continues, and then again they commit at their end of the day. This is how it works. So now let me see, on top of the way you work in agile, what else can be important, okay? So remote pairing, I've seen, is very, very important. We started doing the distributed pairing, and it gives very good results. So basically, there are tools available with which you can switch. So right now I'm working for 30 minutes, for example. I'm finished with my test case and the work. I committed, the other guy starts working from there, and they continue in the pairing hours. So good thing I like about the remote pairing is that you don't need to, I mean, you are very comfortable on your machine, fine? You don't need to sit like this or that. So you are in a very comfortable position, and the communication, I mean, you need to communicate, you have to speak. I mean, one of the important things about the peer programming is the communication. If you're not doing the communication with your peer, then basically it will not work. In the remote pairing, you have to communicate because that's the only way to make sure that other person is listening or working. Makes sense? So I've seen the remote pairing working very well, and we started doing that when people were working from their home. And we prepared it from there as well. So, any questions on that? So basically, this is a picture I have taken from somewhere. But personally, what we do is we use Skype screen share or there are other tools available as well. So for example, for the screen share, there is join.me. You can do the screen share with that. And with the Skype, you can do the voice communication. And what is there a feeling of satisfaction or dissatisfaction with the remote pairing? I've seen that it gives a good amount of dividends. I feel that after working for two hours, you feel exhausted. Because you are so focused and you are so productive out of working on that. So, any other question on that? People feel happier to do remote pairing, or do they feel happier to do leave me alone? I don't want to do remote pairing, I'd rather work alone. I've seen, I mean, it's a mixed thing. People feel happier because they can focus a lot. I mean, think about it, I can sit on my machine. I can see what is happening instead of working like this. So you can sit comfortably and work comfortably and you can listen properly. So earlier there was a problem, like we had lower bandwidth and video communication was not working well. There was a lot of gaps in, I mean, you type and something is not coming. Now it's real time all the time. So I've seen teams working in this fashion only. I'm talking about the teams like, for example, who are working across the geographies and every team member is working from home. So this is a kind of pattern, it's called virtual collocation. So as I mentioned, I want to have a one team feeling. I want to have a feeling that somebody is over there and somebody is over here as well. It's not like I'm looking at this person or looking at that person. It's more to make sure that we are feeling as one team. So this is a Skype camera over there and that camera can see what these people, who are at this particular moment. So it happens many times that I want to talk to that person. But his Skype status show that it is green. But originally that guy is not available. He has gone for the coffee. So then I think that this guy is not answering my message. Something is wrong. So that happens a lot or basically you send a Skype message. He's not answering because he's focused on his work and he's not able to see the Skype messages. With this kind of mechanism, you can see what people are doing who are available. So in case that guy is not available, you can ask the person to inform that person and that's how it works, okay? Local retrospective, this we felt very important when we started working with as a vendor, with a customer, and we were working in an augmented team. Augmented team means like there were some developers in Netherlands, for example, and we were some developers working from India. So then the problem is that when you have a distributed retrospective, then you cannot mention the local problem to the customer. It's very difficult. So something, our infrastructure is not working. So I cannot mention that in the distributed retrospective because of obvious reasons. Or I have some problems with my team members over here. I cannot mention that in the distributed retrospective. So we were feeling that those kind of forces in our teams and we were not sure how to handle that because we were not having any kind of local retrospective. So what we started doing was to focus only on the local problems, we started doing the local retrospective. And that paid a huge dividends. So for example, if you think about this distributed teams, it's the kind of only way to see how for a customer, only way to see how the team is doing is through the, for example, distributed standard, for example. And think about a situation where there is a person who is a very introvert. He doesn't speak much and there is one person who speaks a lot, fine? So in that situation, what happens is though this guy works a lot, but he's not able to speak. And similarly, that person who is very extrovert doesn't work, but he's able to speak very good things in front of the customer. So that situation happened in our project as well. But we were not able to discuss in the distributed retrospective. So then we started having a local focus and we resolved those problems locally. So that is very important, I feel, if you're working in this kind of mode. Then pseudo product owner and specs by example. Specification by example, I think people I heard in the last two days a lot. So this is a situation which is a very real situation. I mean, it happens to many of us over here that the product owner is not available, he is very busy man, I am asking a question, he's taking three days to answer the question. And what happens because of that? The cycle time to really understand the story takes this much instead of this much. And it impacts indirectly on my productivity. It looks like I'm taking seven days to finish the story. But originally, I'm stuck because I'm getting to and for answers and it is taking a lot of time. And it happens in many teams. So one idea is that, okay, fine, we cannot do anything. Let's script and do nothing about it. So that is one situation where you just say, okay, product one is not working well and we cannot do much about this. Another situation is let's do something about it. And this is another situation that let's do something about this. So here the QA or a business analyst moves to the on site. And basically he interacts with the product owner. He doesn't replace the product owner, but he makes sure that whatever answers you need to have for the on show of your team, you're getting it from there, make sense? So basically this QA guy can, or a business analyst guy, can interact with the product owner in their whole day. But we just have very limited time window in which he's available or he's not available and then we're gone. So basically this guy sits over there and then make sure that the information is communicated to the team in India. So this works very well. But now what I'm adding on top of that is I'm adding specs by example. So what this guy does is apart from making sure that we understand the story properly, what this guy does is he creates the acceptance criteria in specification by example, in an executable spec. Makes sense? So now he creates a user story based on a discussion with the team and creates this executable spec. Then the team has to implement those executable spec to make sure definition of done is there. So if those acceptance criterias are met by your coding, then your story is done. So there is no communication gap anymore, makes sense? Any questions on that? This is how a acceptance criteria looks like. So basically we talk about acceptance criteria, but I think we need to understand what specification by example is all about. You have specs, but with examples you get more clarity. Fine? I say something to you, this is acceptance criteria and then you say, give me example. So this is where the example fits in over there. So when I say that customer who buys two albums get an album free. So I'm giving an example. One album, no, two album, yes. This is a very simple example, but it can be difficult examples, complex example as well. But the idea is same. So based on that, this guy creates the acceptance test cases, executable spec, and the team executes them. So then this is more like a governance model, not bold pattern. And this we felt and we thought that there is a lot of technical communication which is happening through the different ceremonies like stand up and whatever, but they're all technical. I mean it's all about like what did you do and there are some problems I'm facing, let's pair up, it's more, I mean about the project and development stuff. But what is happening in the team, what is it? What is the trust factor over there? Is there something, is there some problem is coming from this and that, that end? That kind of discussion never happens about the humans, fine? So that's where we thought like the scrum master over there and local scrum master over here, they just have a chit chat. How things are going? How is scrum, the sprint is moving? Are you facing any problems? How is the, how is the team feeling right now? Those kind of questions. So they are not technical, they are more about how team is working together, right? If you have this kind of communication, it has nothing to be the scrum, it is a human interaction and that is, that gave a lot of dividend to us because we could find the problems or some kind of mistrust which was happening earlier before it could come to us. And then we could do something about this, okay? Then this is a very, very important thing I would like to mention over here, whoever is working in the distributed fashion right now, they have to understand the importance of the backlog grooming and the definition of ready. If they don't understand then, I mean, I have seen that at least 60 to 70% people have problems because of this. And the idea, just to make sure that everybody understands what the definition of ready is all about. If, I mean, customer wants a done product, everybody, I mean, everybody knows about it, isn't it? And there is a definition of done, that compilation should be there, unit test cases are there and things like that, so many things are there. But as a team member, I also want to make sure that give me the ready use story, doesn't it make sense? And ready means what? Ready means, as a team, we have no outstanding questions that stop us from working on this, be it test, dev or whatever. So that means we really understand what the user is all about. There is no third party dependency, which can stop us when we're working on that. There is no unanswered questions, which can stop us because of those unanswered questions only, there is a lot of to and fro in the distributed way of working, isn't it? So I mean, I started working in user story and then I found, I don't know about what should happen in this kind of situation. And then I ask the product owner, and product owner takes two days to answer. So think about it, like your cycle time has increased to one day to two, three days, isn't it? So what you need to do is, you need to do the backlog grooming behind the scene. You have to make sure that only ready user stories are considered for the sprint planning. If the user stories are not ready, do not take them into the sprint planning. So to make the user story ready, you need to do the backlog grooming. And that happens before sprint planning really starts. Make sense? Yeah, so that's where I'm coming here. So this is a kind of roadmap of the next three iterations. So this is a Kanban board for the product owner. He can say that fine, in the iteration plus three, these are the kind of cards I want to see. And that may change basically, depending on the prioritization, fine? So, and in the iteration plus two, this is how, these are the stories I want, these are the stories I want in this iteration plus one. But as you move from the left to right, left to right, yeah. Left to right, then the clarity on the user stories much becomes much, much clearer. Here, I just know that this user story will be there, but I don't know the clarity. Now as you move forward in the backlog grooming, then the clarity becomes increasing and increasing. But important point is, until and unless there is a scar in the ready to play column, you cannot consider that as part of the planning. Make sense? Even though this car is iteration plus one, it's not ready, fine? That then I cannot consider as part of the planning meeting. Make sense? So we have a roadmap that these are the cards which are coming and we can focus and groom these cards in this fashion. So that should be visible to the team and this board should be there with the protocol. So the thing is that as soon as you feel that enough information is there on that card, estimated then and there, that's it finished, it's ready. Why do you need to pick that card again if that is discussed already in the backlog grooming and it's ready? If you have enough information about that card, make it ready, estimate it, move it to the ready to play column and that's it. And you focus on the ready to play cards only in the sprint planning. Make sure that Protono understands that, okay? So this is another one, one team. Sorry, this is, I have written in wrong. It should be one team multiple projects. This pattern works when, for example, you have a team of five people working in a maintenance way of working. Sometimes you have a lot of work, sometimes you don't. Sometimes this team, this guy is having a lot of work, sometimes not. So what do you do in that kind of situation? So what we did was we started doing the pairing session between these team members, make them cross-killed. So when the crunch situation comes into the another project, then that particular guy can support it. And now customer can also decide the priority base, they're not based on the person available, but based on the business need. So skill set means like there is one project which is in sub-technology, I mean similar kind of technology stack. I mean if it is a, it is a similar skill set. It's not like this guy is working in dot knight, this guy is working in Java. Only thing is this guy, two guys are working in Java, but they are working in different frameworks. So this guy can learn new framework. And this guy can also learn domain knowledge based on the pairing experience. So I'm not saying that this is going to work from day one, but based on the pairing session with other guy, you will learn. You will gain the new skill and you can apply that when the crunch situation comes. So this is about distributed co-located teams in opposite time zones, fine? So let's see how it's going to work. So first and foremost important thing is that in order to make it work, they need to have work as a one team which means shared vision, communication, shared ownership, shared goals, active participation. So that, so they should really work and consider as one team and not, this is offshore team, this is our own show team. They should have one git repository to work together. They should work on the user story they need to work on. So first important thing is to make sure that they are working as one team. Second thing is create overlap. So what we did in our case is like we started creating an overlap where for example, US team come a little early and we start a little late. Instead of coming in office at nine, we start coming at 11 and then we had an overlap of two hours or three hours, fine? In these four, in these two or three hours, there is no local meetings in the overlap hours, as I mentioned before. So if I need to talk to that, a person in the outside that guy will be available because he's not doing any local meeting over there. Make sense? Scrum meetings attended by the whole team otherwise not going to work, yeah. So all the scrum meetings? Yes. Continuous gap backlog grooming. I think this is taken from the previous one now also, but I think I'm just trying to make sure we understand what backlog grooming means. In the, as an epic comes, it comes as a rock. And then you start drilling down it and slice, slice, slice, slice. As it moves the sprint, it is smallest user stories. So this is how, this is a kind of backlog grooming iceberg. So as it moves up, then it becomes smaller and smaller and smaller. So backlog grooming is a very, very important thing in order to work in the distributed fashion in the opposite time zones as well. But I think the most important factor is this. But at the same time, it should not be like local team is also coming at nine o'clock but they're staying at nine o'clock in the evening as well. Then it's not going to work. I mean, the US team has to come early, this team has to start late, then it can work. Can you give me a taste of the time overlaps that this team did? So 12 hours, 12, 12, 12, five hours. Meaning what time did the team come in? Did they stay, did they start in the morning or did they start late? So for example, we started late at 11 o'clock. 11 a.m. Okay. 11 a.m. And then we stayed a little late in the evening. Oh, okay. And then the US team come a little early. What time about? Around eight. Okay. Cool. Thanks. So basically both of these teams have to make some compromise to make it work. Otherwise it's not like just one team has to sacrifice everything. So that's all about it. And any questions? Though I have other things as well, but that will take a lot of time. So any questions? Any questions on any distributed stuff? Yeah. Hello? Yeah. Can you say it again? Was it challenging to get people to agree to work in an overlap timeframe for the two different teams to one team to come in early, one team to come in late? I think one of the things I want to mention here is this is a team norms, which I want to mention here. Irrespective of whatever team you're working, whether it's a local, distributed or whatever, make sure that when you start, when you start forming the team, you basically create some set of norms within a team. So that you know this is how we're going to work together. Norms means that this is the way best, I mean, this is the best way I want to work in a team and these are the values I really, really, really care about. If that doesn't happen, that will be difficult for me to work in a team. So basically you define those norms beforehand at the beginning of the project and everybody is aware about it. If somebody violates, then you come to know, I mean, the person can say, oh, you have violated this norm, why, I mean, what's the problem? So in order to create a team, it's, I think it is very, very important to have some kind of team norms and that really helped our teams. I would say that this should be kind of very important pattern should be considered, I think, as far as female. See the thing is that you need to have the feedback. In order, if something is not working, you need to have the feedback and feedback happens through the retrospective. If your retrospective was too far away, then that feedback will be gone. So you should have smaller sprints, fine? At least two weeks, I mean, at most two weeks, I would say. If it is four weeks, then by the time you go to the retrospective, you forget them or, I mean, there are other things which came into the, into the, so it is important that you have a mechanism or a forum where you can discuss these feedbacks and that the feed retrospective is the one and in order to make retrospective work, the spin cycle should be smaller. Any other question? Thank you very much for joining the session. Thank you.