 Thank you. Good afternoon. I'm Kamalesh Ravlani and the topic for the session is the large-scale product development. I'm going to present a case study from the work I did with the company in New York sometime back. So I double-checked with them. They're like, okay, it's not secret anymore. So go ahead. So cool. A quick, I would like to understand who's here in terms of your size in product development. So can we all stand up and position ourselves in the room? If your team size is about the team that you work with, lead, coach, train, about 10 team members, product development team size 10, and 1,000 on that side, that side of the room. So if you're about say, 250, 100, somewhere in the middle of the room. So that would be our horizon. So if your product development team size is about 10, roughly around that, any number of team members working on one product development. So about 10 on this side, about 1,000 on that side of the room. All right, let's move. Yes. Please arrange yourself. Talk to the person next to you. No, no, no, no. Come on. Come here. No, it's afternoon. How can I let you sit? Afternoon. Yes. Yes. Come this side of the room, please. Come this side of the room. All of you. Okay. How many team members? 200. Team members. How many team members? 600. How many teams? 500. Okay. Come here. How many team members? Yeah. Come here. Come here. How about you? Those on the chairs, you need to come up. You need to come up. Yes. Yeah. Come up here. Here. Line up here. Because I'm going to send you for some other reason on that side of the corner. So you all got to be here. Okay. How about you guys? Okay. You got to, what are you negotiating? How many? Come on. Please come in. Come in the front of the room, please. Okay. So roughly 10, 20, 40s, about 200, 300s here, and about 600 plus that side. Okay. Cool. Okay. Now, your closeness to code. Do you write, review, look at the code frequently, at least few times a week, this side of the room. Okay. And if you don't ever look at the code, that side of the room. Okay. Or anyway, the product code, the code of the product that is being developed, whether you touch the code, write it, review it, refactor, whatever you do with the code. But if you don't do anything with the code, go to that end of the room. And if you are somewhere in the middle, okay, once in a while, that will be this side of the room. This side closeness to code, if you touch the code few times a week, this side, if you don't, then that side of the room. Okay. So this is called sociograph. And that tells us who's in the room. And most likely what I'm going to safely assume that all of you either lead teams, coach them to make the product development happen. Okay. Safe assumption? Yeah, cool. All right. Come take your seats, please. Thank you. So a quick introduction. I'm a coach and a trainer. I've been helping organizations lead large scale product development for a good time now. I also conduct private and public trainings on Scrum as well as less, which is the large scale product development. And the history that I'm going to share today has elements from large scale Scrum. Okay. If you are tweeting, that's the hashtag less works. That's my Twitter ID. Hi. So yes, how many of you know less framework? At least an hour or two of introduction if you have had, please raise your hand. At least an hour or two of introduction if you had, I would like to see your hands up. Okay. So about 40% of this room. Okay. So I created a poster for you guys. Feel free to go here. It is, this one is L, both are L. LL, this is capital C. Go ahead and download it. That should give you a good, very brief idea about the framework. On this side, these are all the less rules. And as you, you see some diagrams. Make sure you download this in 24 hours. I'm going to take this, take it down after that. That's a good before coming here. Okay. Done writing it or taking picture of it. It's G double O dot GL slash L, capital C, BBSK. All right. So a quick agenda. I'm going to obviously talk about the large scale product development. Some elements of organizational structure design, multi-site product development. I'm going to talk about the teams that I was working with in US and Ukraine. And the challenges that we had, actually we had a number of many, many challenges. I'm going to address only a few here, depending on how much time we had. Okay. All right. So, the company wireless generation product development company, mid-size, medium-size company in New York, Brooklyn, New York. The product was used for online assessments of school students in certain grades. I'm going to omit some, some fine details just to keep it good enough for them. Okay. This product was being sold by this company for many, many years on the traditional channels. But now they had embarked upon a new initiative which would enable students and teachers actually to do this assessment on any of the mobile device. Okay. Whether it was iPad or any of the mobile device. So, primarily for the students, okay, for them to be able to do assessments on mobile as well as mobile web. But should be obviously, obviously operating system agnostic and device agnostic. So, multiple device sizes should be supported by the new product. It had obviously timeline when the school year starts, the school districts in U.S., if they had to buy a product, they would buy this, they would make this decision much earlier, much before the school year starts, so that all the admin and installation provisioning all is done. As soon as the school year starts, the session starts, the teachers can provision or proctor the assessments for the students at the beginning of the year. And later, during mid-year and then at the end of the year, they do this assessment again to review how the student is doing on reading, math and all those skills. Okay. Basically called DIBLS assessment tools from U.S. or familiar with U.S. education system. Okay, cool. So, you might know some of the terms if your kids were in school. So, this product was DIBLS next assessment. Okay. So, started with one product owner having one product backlog. Now, this product had many modules. And each module could actually be sold separately, but they all could exist within one product as well, depending on what the customers buy. Okay. So, for this initiative, we had all the modules in scope that need to be supported on the mobile device. Now, then customer can save. Instead of five, I need to only buy three of them. But some customer may choose to buy all of them. So, we had to ensure all of these were supported. Okay. So, after the initial product backlog workshop that was conducted with a few of the team members, the architect and the product owner, everything was put on the wall, the cards on which the stories were written. And high-level estimation was carried out, a three-day exercise. And after that, they realized that one team is not going to make it, because we had a specific timeline on which we had to deliver. Okay. If we missed that timeline, what's going to happen? We missed the entire year of opportunity, because now school districts can't buy our product this year. We have to wait one more year, which is a killer. So, we have to deliver. Okay. So, we had to get more team members on the team so that this product would be launched on time. Okay. Now, it was not about a team or two or three. We needed five to 60. So, we had few options. I had about, you know, 40-plus new developers in New York, which is a pretty easy challenge to have, isn't it? Usually, hiring one good team member, a product developer may take about a three-month time limit. Okay. You could get many team members, but it wasn't the case that team, the organization had good policies. I really appreciate that. I've seen with less organizations that if they were not able to find real quality product developers, they would rather not hire them, instead of filling in with anybody in the team. Okay. Or move some team members from another initiatives, which could be lower priority and move them here, because this was the bread and butter of the organization, the primary product for the organization. Move team members or maybe get some contractors. Okay. So, they can work with the team and help the team with product development or completely outsource the product. Okay. Now, obviously, each of these have their own challenges. Okay. Keeping the timelines in the mind, hiring all the new team members was not possible, because it was going to take a lot of time and the new team members would take time to understand the product, the business in the first place. Yeah. That was one. And developing mobile applications at that time wasn't pretty, pretty commonplace at that time. Okay. So, that was a challenge to find people who would know mobile program. Okay. Who would understand what was it needed for it to support on iOS or Android or other different browsers, Safari. Now, moving team members, obviously, it wasn't easy, because who would say that, all right, go ahead, take my team members, because even other products have their own challenges and their timelines to me. Okay. Getting contractors had their own challenges that interviewing and ability to find right contractors was again a challenge. Okay. So, we did initiate the the item number two, three and four, Simas, exploring all these options at one time, started to explore that which item, which option is going to work out well for us. Okay. We started looking into, okay, can we move team members? Are there projects where we have opportunity, even few? Can we get a company, a vendor, outsource, get some contractors or outsource us to a complete product development organization? We started exploring all three of them. Okay. But obviously, when you are scaling, you have other challenges. Okay. So, I conduct large-scale product development, training, coaching, frequently ask my groups, that, okay, what are your big major challenges with the scale? So, these things come up. I'm not pulling you right now, but I think this is the consensus what I have been getting. The dependencies, coordination among team members, prioritization, time differences, because people are in different places, there's a lot of risk that we need to manage. Things can, you know, fall, people can drop the ball. Accountability, who was responsible for X and who was responsible for Y. Access to customer, customer cannot be every site. Conflicts, integrating the large number of code changes that are happening every day. So, all these changes, all these challenges with the scale. Okay. This one framework came handy. We had Pete Barrens as an enterprise coach working with this organization a year before this initiative started. Okay. So, a lot of good work that he had done within the organization also came in handy, though when this initiative was started, he was not part of the coaching team there. Okay. Okay. Some of the less principles I'm going to briefly talk about. These are the 10 key principles that are less based on. So, less framework is distributed in two different frameworks. One framework that specifically addresses between two to eight teams and less huge framework that has little more rules and guidance when you have more than eight teams and that's exactly why I wanted to know that who's in the room here. Okay. So, I think for most of us here in the room, this framework pretty much can suffice the need that we have. Okay. Now, less structure specifically talks about having real teams. Now, if we were to get some contractors onboarded and work with the full-time employees, it wouldn't make a team because they would come and they would go. Okay. And as we know from, you know, team-based researchers that it takes time for a team to pass through different stages for it to become a performing team. Okay. Usually, more than a year. So, this wasn't going to help us here. Another thing that less talks about is having feature-based teams, which have ability to pick up a product feature, implement it and deliver it in its entirety without being dependent on any other teams. Now, that also means that if there were dependencies on the backend, excuse me, some database changes have to happen. API's middle-layer changes have to happen. APIs need to be re-written, over-done. Front-end client-face code needs to be re-written. This team is able to do all of that itself. Okay. So, let me dig a little deeper into what challenges we face when we have component-based teams. Okay. Not feature teams, but component-based teams. Who are in any of the less sessions before this morning? Sessions where less specific conversations happen or feature team conversations happen. So, let's take a scenario. We have about nine teams. Okay. We are doing release one of a product and say we have three major features that we are addressing in this release. Okay. Now, each of this team have ownership of one component in the entire system. Now, take for example, feature one. It needs changes by team number one, team number four, team number five, and team number eight. So, these four teams need to make code changes before feature one can be deployed. Okay. So, obviously, as soon as we kick-start the initiative, team one is going to start working on this feature. They'll hand it off to team number four, and it's going to pass until all this work is done. Feature one will be in progress. Okay. Now, while this is happening, feature two can start. Okay. Now, feature two needs team work from these teams. Team number one, team number four, seven, and eight. Now, while team one is working on feature number one, in this case, feature number two has to wait. And as soon as team one is done with the changes for feature number one, they can now pick up feature number two. Okay. And same for team number four. And say feature number three has a dependency on different components. And this, these teams have to make changes into the code. Now, what is happening here is each team is making a part changes in the entire system to complete a feature. So, there's a lot of learning whenever we are making any code changes. Okay. There's learning there. Now, each team is generating some new learning, but now this learning is only focused on one component rather than serving the customer need or solving the system's problem. Okay. Now, some learning that is happening in team one for feature one that needs to be passed on to team number four so that when they make changes for feature number one, they understand that why these decisions were made, what assumptions were taken, what challenges did they face. Okay. Is this the best approach that team one came up with? And why is that? Okay. So, all this learning needs to be passed on. And similarly, all the, all the respective teams need to pass this learnings to other teams for that team to really have good context about what all these decisions have been made so far. Yeah. These are nine teams, for example. Okay. Nine different teams having ownership of nine different components. Now, let me ask you guys, how many times a component team that has made changes and passed on the ball to another team's plate, shares that knowledge with them, passes on that learning, those assumptions, those basis for decision making to the other team so that that learning is shared. Few hands are good. What we usually see is this knowledge is not being shared consistently. Okay. So now team two has to start from fresh. These are good, capable, technical, technically competent people. So they can also make their choices. But now the only challenge is they have to start from fresh. And now their assumptions could be a little different or their way of solving this problem could be a little different. Okay. So that challenge. Now, while team one is busy, team four is really busy, some teams have lighter workloads. Right. Some teams have nowhere in this release. So what is going to happen in those teams while release one is in progress? Obviously, they are not sitting idle. So they have found some other word to keep them busy. Isn't it? No team in my organization or any organization I have been to was sitting idle. Okay. Which means they were doing something. But now the thing is release one is the highest priority release for the organization for this quarter or this year. So rather we focusing all our energy effort on the highest priority, what we are doing is we are optimizing for people's time. Yes, we are doing local optimization. What we are doing is because this team is sitting idle, what does this team's manager going to do? They're going to go and find somewhere and make sure that team status reports or progress reports or time sheets show that they're busy. This may not be the highest value for the organization for this reason. Number one. Number two, what if when these teams are really, really busy and because of these teams are busy and timeline is critical, what is going to happen within these teams? What are the managers of these teams going to do? They are going to start looking to hire more people so that they don't become impairments for the organization and releasing these products. Is that true? And what happens in traditional organization? The number of people I lead, the amount of budget I control, what that signifies? And who does not want that? So that's again local optimization is happening at that team level. Teams that are busy, local optimization is happening here. So these teams are hiring more people, they are onboarding more people so that more work could be cranked out by these teams. Now guess what? Release one is over. Cool, great, good success. Release two starts. And now, coincidentally, release two had all of the work going from this channel. Boom, boom, here. What happens to all these large sized teams? Yes. But are we going to sit idle? No, we're not going to sit idle. So what we are going to do? We're again going to find something to keep us busy. Sorry, fix the box. Could be. Again, we are going to do the local optimization here with component teams. So component teams cost a lot of ways. Actually, all of this, all of this and a lot of it. I'm sure you're familiar with the seven ways of lean product development. Mary and Tom have popularized this for the software context as well, making it eight. So how did we solve it? We definitely did not want component teams because we were very familiar that it would be a lot of ways. And we always wanted feature based real teams. But now hiring so many people was not possible for us in that time. So what we did? We identified one product initiative, which was getting close to finish. So we were able to negotiate and move one team, entire team from that product group to ours. We did not pick up one person from this team, two people from that team and one from another team. We moved entire team because this team was a team. They knew the working agreements. They knew the process. They knew each other. That was the asset for us. So we moved completely one team. Now we had two teams in New York, but that was not even close to what we really wanted. Yes, both actually 50-50. So one product was about to wrap up. And we were able to discuss with them, based on the priority this product initiative had, we had to negotiate with their product group and move the entire team. So we did not have component teams. The point I wanted to make with the component teams is it is a lot of waste. So we did not want to have component teams. So we wanted to have feature teams. Other product, this product. Yes, definitely the team members need to learn the new product. They need to learn the technical skill a little bit. But the good thing for this team was, team number two was that they were within the organization. So they knew a lot of stuff already. They knew the team's culture, the organizational culture. They knew the engineering practices. And also we were able to find a vendor which had worked for this company in the past and able to work with them to onboard three new teams from the vendor side in Ukraine. This was in Brooklyn, New York, and the vendors were in Ukraine. On board three new teams with them. So how did it happen? For the first two sprints, they sent about four core of their tech leads to the New York office. And they worked with these teams as team members for two sprints, complete two sprints. So they were part of the sprint planning. They were writing the code. They were delivering checking in. They were part of the reviews. So rather than giving like a knowledge transition in a conference room, they were given access and they had to work with the team. They were equally responsible for developing, working on the stories and delivering. So we thought that was that was real critical because once they go back and they have already seen all the challenges, they have already worked on entire cycle of right from planning, picking up a story to delivering it. They will be able to share that with the new team members who join in Ukraine. So we were able to get three teams in Ukraine. So we had two teams here in New York and three in this. We still had one product owner who was responsible for all the modules, making all the decisions. And we were lucky. We had really great product owner who had been working on this product for a long time. So she really knew the product very well. And still the product backlog was single. One product backlog. We did not have multiple product backlogs. Though our product backlogs did have items from different modules, the product backlog did have items that belong to different modules. And if we were to segregate them, it would look like this. So which very conveniently helped us for the teams to pick up work related to a particular module. Now it was not like written in stone. So team members did have flexibility which one they want to pick. But they themselves identified that it would make sense for one team to really work on one module so that they really understand what are they solving for. And there were common components, shared libraries that they were discussing all the time. That who is going to work on these on the shared ones. One spring master for the New York teams. One spring master for the Ukraine teams. Another challenge. So I talked about the talent, getting teams. Now having feature-based teams, if you are able to have that in place, I personally think that your half battle is one right there. Two, communication and coordination. Now this is half, as I said, half the battle is already one when we have feature-based teams. If we had component-based teams, we had to have some people who would do coordination. We would need to have somebody who knows this and says, okay, we are working on this. This is the date we will deliver. And then when are you going to pick up? When will you deliver? So this team is ready accordingly. Somebody had to do all this coordination. Oh, you deliver a beautiful thing, but now it doesn't work for us. Okay, so back and forth. Somebody needs to coordinate. Oh, this component, that component, that component. Somebody needs to integrate everything. Who's going to do the system integration testing? Somebody needs to coordinate all this. But here, a lot of these things are already solved. So we know that a lot of projects actually fail just because they have lack of communication. They don't have good communication practices in place. And honestly, this is a very conservative number. Actual numbers could be much higher than this. Sorry. No, so there are many studies. So some studies even say 70 percent. Sorry. Yes, but again, I have mentioned the source. So there are many studies done by different groups. So some group call it 70 percent. Some group call it this one. I found this one to be more resonating with the audience. We are all familiar with this, the richness of communication, face to face, the best one. So how are we doing it? Okay, so that's like two concentric circles representing a clock. So we had daily scum in New York for the New York teams. Each team had their own daily scum and daily scum done by the Ukraine teams. They had their own daily scum. So what were we using as a communication channels? So we had internal instant messenger, Jabber. So every single morning, somebody would initiate a group chat and call in every team member in there. So all the day, if something was important, they found something useful or they ran into some issue, they would just post it on the messenger chat group. Hey, who can help me here? So from all of our documents or any information that we were writing were on the wiki. We did not deep freeze the information on a SharePoint where everybody had to come and ask for access. But this was available within the organization. Anybody can actually go and see which stories are part of this team's sprint plan, this sprint. Or what are the outcomes from this sprint? So it was accessible for everybody within the organization. We had the internal corporate kind of a Facebook alternate was called Yammer. That actually helped promote a lot of good collaboration within the organization. So anybody like once our director of engineering he found something and he post on our Yammer group that hey, this is something I'm kind of challenged with, who can address. So anybody within the organization, not necessarily part of that team can respond back or post, hey, we already have the answer for this. Video messaging Skype, we frequently use this, especially with the Ukraine teams. We did not have any, we did not buy any electronic tools. And that's exactly why I wanted to put this slide on. The physical scum board worked super cool for both teams in New York as well as in Ukraine. The whiteboards were all the time being used. We had so many whiteboards across the walls. Whenever team members had something to discuss, they would just get up and go and talk on the whiteboard. They would draw it. I think that's a very good practice that teams can benefit. And once in a while, we use Excel sheets. Once in a while. All right, the coordination now across the teams. So there were more teams now. And sometimes things need to be exchanged, communicated. So we had Scrum of Scrum in New York that was daily basis about 12 representatives from different teams. Now not only this product group, but from different product groups would show up here for 15 minutes and discuss if they had any major impediments that were organizational level impediments, any major releases coming up or some like infrastructure upgrade going on or something that's going to be down. So that would be communicated so that you can go and bring in that information, share with the team that, hey, this is going to be the servers are these servers are going to be upgraded from this to this time, don't deploy or something like that. Or we are going to launch on this. So keep an eye on it. So any team representative team member would usually go not your Scrum master or not your product may choose to go and observe it once in a while. But ideally you would want to have a team member who's close to the action, the code usually would go and talk and share information or exchange information with other team representatives. Now there was as I mentioned completely opposite times 10 a.m. here and other happening at the 10 p.m. That's why it was dark obviously. So we wanted some information exchange so that if the team in Ukraine had some questions for the engineering team they could at least have a talk. Though they were part of the group messenger, so group chatting. So anything that was happening in the team in the New York time when they log in they come up and they see oh this was something was being discussed. So that was super cool. They didn't have to like ask or call somebody say share something with me that was cool that you guys discussed but everything was available to them. So there was no kind of employee versus contractor kind of a limitation on information exchange. Everybody had the information. So usually we would once in a week either Thursday night or some night both the representatives from New York team and Ukraine team would get together and do like a weekly sync up that are we all good? Are we following good practices? Is continuous integration working well that are if some bill was broken did we do it the right way or can we find something better to do it? This was not a retrospective but a quick sync up where any things that were not addressed in the regular communication channels could be brought up and addressed. We had a steering committee meeting twice a month where all the risks would be discussed. Customer input would be discussed. What are the marketing team's plans? How they are progressing? The infrastructure and all those things the funding and all those things will be discussed. Any major impediments that we wanted to share with the leaders of the organization would be opportunity to share with them. We had a once in a month community of practice gathering. Again this is volunteer based knowledge sharing. So you would have the SCUM masters meeting with other SCUM masters architect tech leads meeting with those selenium guys testing community meeting with the testing community sharing good practices within the organization. If some team came up with like a cool library like now we have the graphs you guys can go and use it all those things would be shared. Yes optional it would be a product known as choice. If she's available she wants to go and just listen in that where are my products what are the big impediments or what are the major releases coming up she wanted to just sync up she would go and observe. No so if anything that was discussed within SCUM of SCUM and that had dependency on some leader to address that then the facilitator of the SCUM of SCUM would go and share that with the leaders. No so that's a good question just to separate these out. Staring committee meeting was for this product group where they had five teams and everything specific to this whereas SCUM of SCUM is the organization wide SCUM of SCUM product development release management operations customer support okay so all those people will get together and share any as I said all those things in the SCUM of SCUM okay cool clear good okay all right item number three how are we doing the product reviews okay so we had one product increment every sprint despite having multiple teams different time zones the product increment was one so everybody was continuously checking in we did use tools for continuous integration but eventually we had one product that was being developed and being reviewed okay so when we get together for the sprinterly the tech leads would usually sync up like a quick prep kind of a 15 20-minute check-in with all other team leads or QLEs and saying hey everything in place this is working do we have like stub data or you know we have we want some accounts with some backend data is it everything in place so if customer wants to test this thing will we have like a complete transaction happening right from front database and getting the response in place okay so that would be the sprint review usually we would have our customers in the sprint review so our product owner would take a lead and show it to the customers to seek the feedback now once in a month we instead of going to the regular team level sprint review or a product level sprint review we would actually go for an organization wide product review bizarre where we would set up in like a whole team would set up like a booth within the organization within the teams working area and all the people within the organization the invited guests from obviously customer organizations or potential customers they would come and take a look at what's what's being developed okay so once in a month that would be opportunity and I think this is really really super cool thing for any organization to do because usually team members are so busy with their product development they they usually don't get time to go and see what other products are being developed what progress are they making what modules are being developed what improve improvements that those products have done that many times we would see that other team have a come up with such a super cool like ui cool you know like animations and so we would say why not we should do that too okay or sometimes we would see some good graphs being generated by the reporting team and say could we use those too all those things okay also having broader idea about how the customer looks at us okay now this is one thing important and less framework emphasizes a lot on this okay having the customer centric view now this also informs agitates all the team members about how the customer is going to look at us from a product offering perspective okay now though we are offering we are working on one product but customer is buying more than one product from this organization okay so now customer doesn't care about which product group or line of business developed product a versus product b versus product c they still look at this as an one organization okay so that this bizarre helps you bring in that kind of a shared knowledge and understanding within the teams okay yes you had a question two weeks yes please this was every sprint two two weeks yes that was two weeks and this would be so you would have alternate alternate you have one sprint review for the with the team and then you have within the organization the entire organization then again the third one would be with the team and fourth one would be entire organization okay yes yes that's right yes and actually that was beautiful that is like putting your product development on cruise control five but one product owner working on one product irrespective of how many teams are working on New York yes okay good question so I kind of missed that in sharing in the communication and coordination so product owner was frequently in touch with the teams in Ukraine okay number one number two when they were brought in to New York okay they worked with the team at that time they had good amount of knowledge sharing from product perspective with them okay so one person from those people out of those four people came in one person was working as a product and they were working on completely separate modules so they didn't have to like interact with this product owner on daily basis she was really nice I said that yes she was very knowledgeable and she was very cooperative as well and she was respected within the organization okay last point and then we will wrap up all I'll open up for questions okay so customer collaboration so as I mentioned this product was being developed for the school students to take assessments so now there were multiple users so one would be your admin of the school district who would make the choice of buying it or who would own the product actually and then you would have teachers in the schools respective schools who can actually initiate the assessment and see the report of the class or different students or for the class and you would have actual students who who are guys who actually do the test okay so we would very frequently bring in teachers from different school districts including New York to the office now one thing is that frequently teachers were anyway visiting our office for the training purposes okay so anytime a group of teachers are in the office we would never let them go without showing our products to them and giving their feedback okay so that was like a free feedback for us but also when we had the organizational wide reviews we would bring in some outside school visitors school teachers to come and review the products and give us feedback okay the students the kids okay and fortunately a lot of the team members were parents and their kids could also try this and give them feedback okay so we would usually seek out team members who were willing to have this reviewed with their kids so we would give get the feedback from kids okay we had the internal doc feeding community which would be volunteer based review of products so we would say hey we have this product who would like to test it okay so people will volunteer and then we will send the bill to them and they would test it out give the feedback okay then we had lovely customer support teams working very near and close with the team and they would always bring in valuable input from interacting with customers and give feedback to the team about what is important or what is challenging for the customers how customers are interacting versus how we see it from development perspective okay and wherever there were no customers available our product owner would work as a proxy of our actual users and resolve queries or give the feedback okay yeah that's it so are we on time how much time we have yes i'm open for question but if not thank you thank you for joining thank you yes yes definitely so feature based teams one when critical aspect from the less framework okay now having teams i think this was also discussed earlier session that if you have a team in new york okay this entire team should be in that same location you don't want to have three team members in new york and three team members supporting them from ukraine okay so now the ukraine team is independent of the new york team and they they are feature based teams so they can pick a feature deploy deliver it okay number one you want to have one product owner for the entire product group irrespective of number of teams okay now here we are talking five even if you had like eight teams one product owner should be able to support so that decision making is happening by one person okay prioritization is happening by one person so having one product one backlog okay let's again talks about having one product backlog for all the teams so when the sprint planning is happening everything is being cold based on the priority not based on the availability right what we discussed in the component based teams okay then having your product reviews customers interacting with the team on product reviews okay so now here what we are seeing is product owner is not your go-to-guy for all the query okay so teams actually now talk to the users directly to I say hey if we would put yes now product owners only responsibility the primary responses we would be to prioritize okay based on the organization strategy based on the demand the business value and all those risk factors but the solving of queries okay what should go into a feature or how would our pay now button should look like what you know contrast all those this team members directly as the customer now that also enriches the team with the rich product knowledge okay so now product owner is not the bottleneck for solving all the queries or approving or accepting or denying the user story acceptance okay so now team members are able to directly talk with the users and get it done okay well yes that's right but team teams are not developing a separate product it is one product sorry yes it is still one product so you can show it to a customer irrespective of where the team was or where the feature was developed yes yes you are you yes you you you are very right on that yes and an unfortunate thing in Ukraine would be that they did not they do not have those students or teachers who they can directly reach out because this was for the New York users yes I totally agree yes so sprint planning was same as your two weeks crumb would have like your beginning of your sprint half day you would save four four hours so Ukraine team would do their own sprint planning okay when they would come into the office they would do their own sprint planning and they would show that okay these are the features that we have picked up and it would be all on one wiki so for example save team in New York they were doing the reading module okay and the team in team in Ukraine is doing the math module yes it's it's again you know basically going to scrum not a good practice to compare velocity between teams no we we purposely did not want to compare velocities across the team right well thank you yes hope it was valuable thank you