 Okay, so this is the topic I am going to talk about. This is going to be an experience report which we ran. I am going to explain. Do you guys have any idea what I am going to talk about? Team self-design, self-organization, what is self-organization? We all know self-organization, right? So that is a very important thing in agile software development or for that matter achieving anything, any great results, you need self-organization, right? What is self-design? The self-design is letting people to choose their teams. So the teams, the team members say, okay, this is the team I want to work in. The concept is, if the teams are formed that way, they self-organize faster and better. So that is the idea. The idea is actually taken from one of the blogs by Craig Larmann. And so we implemented this as part of a large scale transformation I worked in last year. I am going to take this experience report and show you how we did it and what happened and what are some of the issues we faced. And my name is Nanda Lankalapalli and I am from Hyderabad. And I'm an agile trainer, coach, practitioner, architect. I do software every day plus I do other stuff too. So that's about me, quickly. And early on I had the opportunity, I'm very fortunate to work with Mike Kohn. He was my manager for a year and also Lisa Crispin. She was on my team for about four years. And so Lisa Crispin is the agile tester and Mike Kohn probably a lot of you know for a mountain good software. Okay, I just want to set the context here. The global context is this is a large scale, large organization, thousand plus employees worldwide and eight different locations. And the very good thing is there is a C level support for this whole transformation. There is a CTO who was hired just for this transformation. Who is very good, he can tell anything about agile and he can just tell you what, who said in what page of what book kind of knowledge. And he has a lot of support and there are ten coaches are more worldwide and the transformation is mentored by Craig Lorman at a very high level. The senior executives level and so we used less framework for scaling that is prescribed by Craig Lorman. So this is called large scale scrum framework. I'm not going to go over the framework itself because the scope of this talk is to show how we did the self design, not really the whole transformation, okay. So this is the global context, Indian context, the 600 employees in India and most of the development happened in India and happening right now. And Indian employees are all co-located. The code base is probably not very uncommon, not a lot of automation and all that, not a lot of knowledge about agile, six agile coaches in India. And I was leading the transformation effort in India and coaches are all empowered, that is again the great thing. So all coaches, they can do whatever they think is the best with the retrospection within the community coach team, all these ten coaches. And so the CTO empowered all the coaches and they can go and tell managers what is the right thing to do. And managers are all directed to follow what coaches are saying. So that much empowerment is there. So which made a lot of things easy, right? It's not easy otherwise you go as a coach you go and say hey, can you need to do this, this, this, this, okay, we don't care. Then there is a problem, right? That problem is not there in this transformation, which is a nice thing. So the existing team structure prior to the transformation is a component team. I'm going to touch upon what is component team and the feature team in a second. And the dependency on team leaders, like every team has a team leads more like a mini managers. Like they give the estimates, not the whole team does. And they tell what to do and all that stuff. That's very typical, right? And the silo functions like architecture, testing, development, etc. And there are traditional project managers and there are a lot of talks about what typical project managers do, like running around and getting things done and all that. So that's a very typical scenario, right? So this is what it is before prior to the transformation. So I just want to explain a little bit what is the component team. So the component team is cross functional but still handles only one component of the system. They don't handle all the components. A team handles one component, it's a loans team. That means they handle only features related to loans, okay? So that is a component team. It could be cross functional, that means the team itself has testers, developers, architect, everybody is there. But still they handle only one component. So that's a component team. So we have, let's say, three component teams. And there is a one feature that's cutting through all components. Which is very typical in a larger organization with multiple teams. What do you do? Normally, what do you do? You basically break it down into features related to each component. And each component handles only stuff related to their component, right? But how do you do coordination? Is it scrum of scrums? Or you still have project managers, they'll be running around, right? The integration is that you have to create a layer and the new roles on top of these features, these teams to handle all the integration and the coordination part, right? And who does the integration testing? There will be an integration test team or a system test team, right? There's a separate team. So there is a handoff. We have been talked about minimize handoffs and all that in agile. So the component team actually doesn't work very well if you have a cross cutting features which are cutting across several teams, right? You need to have this coordination and all that information gets lost and you get into all kinds of trouble. So what is a feature team? A feature team is a cross functional and also it's a cross component. That means each team, I just made three feature teams out of those three component teams and each team can work on any component. Now they're all cross functional as well as cross component. That is a feature team, right? So as far part of the transformation we decided to go with the feature teams and that is the mandate from the coach community. So that's how we were going to try because feature teams deliver a lot of flexibility. If you have a handful of feature teams, you can deploy. Anybody can work on any feature within the set of components. So that's the idea about feature teams. So you have one feature now coming cutting through these three components. Any team can pick up the feature and do it. Team size is still within the limit of what Scrum says. Yes, to just give you a data point, the team currently I work on. We have about like still less than 10, right? And we handle more than 10 components. So it is possible, like the question is like is it possible for such a small team to handle several components? So if that's the question. So it is still possible, but it requires a lot of learning and so far and how complex your components are and all that stuff. And there are ways to help there. So but this is the concept of feature between the components. So yeah, so there are few things I will talk about. What is the feature team and all that? Because I need to get through the exercise part itself. How we did the self formation and feature teams will see if get time and answer all the questions. Or otherwise I can talk a little also. So the prior structure of this organization is they have like two product lines and they have component in CT stands for component and there is a underlying like a common services where it says authentication service and all that stuff are some of the business services which cater to both products. And also there is an infrastructure teams. So this is the initial structure before we started the transformation. So what we want to go to is a new structure where they divided all the teams into like a logical grouping. They called parts. So the part one, part two are still the product areas. Whereas the common services are divided into multiple parts. And there is one infra part which is again cross cutting for the whole organization which has a DevOps and architecture team which is going to help with the whole organization. This is not like a final, final Nirvana state. It's again the intermediary state they want to get to. And there is something beyond this which I'm not going to talk about at this point. OK, so this is a new structure. What we thought is let's try a pilot. We wanted to go to feature teams with a self, team self design. Is it going to work or not? We don't know what is going to work. What is not going to work? So we thought we'll do a pilot. When we started the transformation, we started coaching each team independently like all the component teams are trained in Scrum, Agile, Lean, and all that, then we were coaching some of these component teams independently. So then at some point of time what we decided, just we picked two component teams and we want to turn them into two feature teams. Just like I showed three blocks earlier, so now we are picking two component teams. Each work agnest or draw work from two different product backlog for two components. Now there will be two feature teams. Both will draw features from common backlog for the both components. OK, so that's the idea. So we wanted to do that pilot. How did we do that? We started like there are two component teams, two team leads, 18 members, one Scrum master to help both teams, and one product owner for both components. And the skills required, the knowledge of each component, and then they have multiple UI components. So they have VC++ client, Object C Mac on Mac, and the web technologies, they use Java, and then it testers or people who know testing, how to do testing, and all that, and the database. So these are the different skills that they need to accomplish the job. And so this is the teams we have. So we need to basically make two feature teams out of this. Now they are business components. Something like for a bank, it's a loan, loan processing component or module. So those are like that, or a bonus system. So those are two different components. So this is what we identified. So I faded the picture so that you don't identify anybody. Because I'm not their employee. If you recognize anybody, don't tell anyone. So the way I did was, we just got all 18 people into a room. We displayed all the requirements. So these are all the skills required. And form into two teams. So what would have happened first round? So they formed into two teams. But what can you expect out of that? Pardon me? The original teams. Because they don't know what to do. They said, OK, let's go and be the team. The same team, what we were. So then we started asking, OK, do you have each team? Do you have a knowledge of this component? Yeah, we do, because that's our team. So do you have a knowledge of this component? No, not much. Then it's a failure. It doesn't work. And then we went over all this. And they said, OK, it's not going to work. You need to fix it, right? So then they understood what I'm trying to do. So they said, OK, they need to get some people who have the knowledge of other components and give away some of the team members of their component. So then they discussed. And then round two, they basically went ahead and did that. And after that, again, we did that. We did check whether still there is a problem. And then there is a problem with something like Mac, because Mac work is very little. So they didn't hire enough people. Earlier it was all like siloed, right? So Mac Center of Excellence, or whatever that team, is catering to multiple teams. Now it won't split evenly, because you have only one resource, or one senior and one junior, or something like that. It won't split very well. So they said, no, no, we can't do it, because we don't have equal split. They said, it's OK, as long as. So the idea is the manager basically came in and said, so don't worry about any skills not being equal. We are going to get more help, or we will train you. Don't worry. So basically, after all the concerns, some of the concerns are discussed, and assurance are given. So people started slowly settling, OK. Now we will split it, and we will slowly learn, and all that stuff. And the same thing happened with the testing. And so they also had some discussions. So testers from each team come, and they discuss, and how they move. And eventually they decided, OK, this is the best split. So these two people work here, two people work in this team. So that's how they decided. So then the final teams are, they came out, and they chose their names, and basically, so this is our team starting now. This is something we chose. And no manager had a say here that you should be in this team or you should be in that team. No team leader had a say, Scrum Master. None of them had a choice to talk. Only team members can decide. The manager can answer only the concerns, like, hey, we don't have any resource in our team. So what do we do? I said, OK, don't worry. I'm going to get you some trainer, or if you are willing to learn the technology, or we'll hire a new person. So that is the pilot, how we did it, as far as the exercise goes. So then after that, we have to coach them, just like the two feature teams equal, and they need to work off of one product backlog, drawing features from both components. And some of the joint backlog meetings, like backlog refinement, print planning, joint retrospectives, and all that stuff, that requires some help, because they can't be done like isolation because it's not any more team effort. It's like both have to be in sync, because when what stories are already done or what features are already done, they both need to know equally. So every joint meeting, all feature teams need to be there. So then they identified gaps in the skill set. What we did was, we ran an exercise where everybody identified, OK, so our team doesn't have this skill and we need help. So then we basically presented all that to manager, and manager said, OK, we will hire somebody, or we arrange a training for that skill. So that's how those gaps are filled, and also everybody came up with their own learning plan. Somebody says, I want to learn this in next three months, and I will be, I will reach the proficiency of working on it without anybody's help. That is not like manager saying that you should learn this in three months. Individually, everybody's saying, I will learn this in six months. That's OK, right? So everybody has their plan, and they put it up on their queues, which they manage and manager only checks once in a while, making sure that they are on the track. Or they don't want to work in either team. No, no, it didn't happen that way because they already work in the same product area. Most of them know each other. So that probably happens when somebody's notoriously, like nobody wants him, right, for whatever reason. That didn't really happen. So team leads became the component guardians. Anybody know what the component guardian is? Or components toward, there are a couple of names. So they are the experts in that component, right? Two team leads. Now their job is 50% they do all the, any knowledge work or anything. Remaining 50%, they will be helping both teams to come up to speed on that particular component. So they are the component guardians. Two component guardians, 50% of the time, they spend helping both teams come up to speed. So they have a plan for technical skills, and they have a plan for domain skills. And they have COP, community of practice for UI. So they have three UI, Mac, Java, like a web application. And also they have EC++. There is a discrepancy between the, whether all three have same features or not. So they want to have a COP for that. So that also came out of this exercise. So they started meeting periodically and discussing about different UI technology so that the cross learning is also happening there for the UI. Sure. Yeah. So that's what I said early on, like there is a high level support. This is coming from top down. So it's not like we have to go and convince the senior management here that this work. They said, we know already it works and you go and implement it. So it's a easy case, right? Yeah, but I can talk to you later like how to convince. That's probably a different question, right? You mean the feature team? So they don't really work in this team, but they can, like if they don't have anything to do, they don't have any other special work to do or teaching or anything scheduled and they can come and contribute to this print. So there is no restriction. It's all inclusive. If somebody comes and say, I want to help, not saying no, we don't want your help, right? If that is going to speed up your delivery, the value wise, right? But the accountability could be a problem. Like how much of the effort should be accounted. So think about it. If that guy is sitting idle versus helping somebody deliver their product quicker, you want that, right? So there is nothing like there is no stop that you can't come and tell us or anything you just do your stuff. They can always come and be part of the team. They attend the meetings and it gives some advices and all that stuff, what to do. And this is again the new team. They're not experts in working in this model. So they definitely need a lot of advice and how to do it. Once the teams mature in this model, probably they don't need somebody sitting like that. So then the team leads will be absorbed into the teams. So that's the idea. So the pilot outcome, team members were initially skeptical. They said, no, it's not going to work. Even managers said that this doesn't work at all, right? Because team, they don't know what they want. I only, I know. So I'll tell them what to do, right? So later he realized that, no, that's not true. He saw teams really doing very well and then later in the transformation said, okay, the exercise worked very well. Okay, so that is about the pilot. Before we go to the much larger transformation, do you have any questions on the pilot? It sounds easy, right? But when you really are in the room and doing facilitation, it'll be very difficult because people don't want to really move, really convince what is the goal, what are you trying to do? See, that is the, yeah. So the question is the velocity would be more if you have expert team on that module, right? It is the same concept of all silos. If you have the testing center of excellence, then your testing will be faster. It's the same mentality, right? It's the same thing applies here too. User wants to deliver. You want everybody in the same team. That feature may be cutting through 10 different modules or components. That is the best way, right? Any other questions? Yeah, it's a one product area, but two different components. Product area could be like, if this is an online gaming company, so you can say poker or bingo. So that's the one product area. Within that, there could be different things like bonuses, you give bonus, I give points and all that stuff. Each one could be its own component. So these two feature teams working for all the features related to two components. They're probably logically grouped. Those two components are related to each other. That's why some of the features are always cross cutting between those components. So it's better to have feature team which works on all components rather than having a separate component. Right, yeah, right. So the thing is, if you don't have enough work in those two components, what will you do, right? That's something a product owner or the business leaders need to foresee. Say, okay, next to one year, we have this much work in this area. So let's have handful of feature teams so that we can deploy all of them and it's not like one component has a lot of work, other component doesn't have any work. You probably have seen in your projects that some teams are working extremely hard and other teams don't have anything to work on. And that problem will go away because now whatever this component, a lot of work is there, both teams are working it. Or in that particular sprint, for example, maybe one or two sprints. Okay, so it is generally the cross learning in any agile teams we talk about, right? So whenever you don't have anything to do, like because one feature has this work, one feature doesn't have this work, then you either spend that time in cross learning other technologies or you clean up your technical debt, write some unit tests and all kinds of stuff. There is so much work already would be there. It's not like you don't have anything to work on. And unless you're saying next three months you don't have any work. But I haven't seen any system which has been running in production for a while, not having any of the technical debt or any gaps, you want to fix it because this is an opportunity to do that. I think one big thing is we want to see the, like we want to optimize the capacity a lot of times. But the problem is that optimizing around delivering the value is more important. Delivering value to the customer is more important. They don't really care how your organization is optimized. One example I give is you go to McDonald's and you say I want a burger. The guy says our system is optimized for 10 burgers. Right, you're the first one, wait for nine more orders. What will you say? You don't like it, right? I don't really care how you optimize. I want my burger now. So optimizing your resources, your organization within is not important compared to delivering value. So I need to come up with some way of delivering value faster, right? So feature teams allows that because it's not like one team is super busy other team is just sitting there. Okay, so the big bang self-design, what they decided is let's go with, so you saw different parts, right? So each one part at a time, each part would have 30 to 40 people. And one part at a time and all teams in the part are trained scrum, agile and lead ahead of the time so that everybody has the knowledge, right? And they all, each part has a different skill set. Earlier I saw show you like VC++ and all that, but some other parts have a different skill set. And each part has a different design. I'll get into the part design a little bit here. So this could be represented as a part design in general. So you will have, every part would have few feature teams, handful of them, we decide how many. And there will be a ring fans team. The ring fans team is basically a expert team. They're still a silo, but they are good in one thing. Something like they're extremely difficult or complex algorithms they have to write and you don't want everybody to write that. You hide some people to do exactly that. So that forms a ring fans team. But as much as possible, you want many, as many feature teams as possible. And minimize to just one or none, ring fans team. And this one is more like, again, similar thing. You have something specific to that part, still cross cutting between all the teams, some support. Again, this is a siloed approach and it's not recommended, you don't want to do it. But as part of a transformation, before you reach that final state, you may have to go through these intermediary steps, which is okay. But the general guidance is not to have any ring fans team and have all the feature teams. So you need to come up with, how do you know how many teams, say, part needs? So first we talk to the product owner and ask, okay, so what is the nature of the work for this product? This product area or this part? They say, okay, so we are going to have this kind of work, this kind of work, this kind of work. This is more like continuous flow of work. These are the features we need to build. Then we decide how many backlogs. You need to have one backlog of all the features and then one backlog of all the individual items which just flow through. So that need to be decided. Then the podmaster, podmaster is nothing but manager's title here. The pod's manager is the podmaster. That's the title they gave. The podmaster identifies how they are going to deliver that. So now we know from product what kind of requirements they have, what kind of the features they're going to build, and the podmaster is going to discuss, basically, come up with how many feature teams, how many ring fence teams, and that kind of stuff, and what skills they need. So preparing for the real day, the big bang day, when we are going to transform all these guys into teams. So we need to know, as a facilitator, I was the facilitator for at least four of these exercises. I did like four reports. And you need to know exactly how many are coming, who are all coming, what are their roles. Because you need to know the ultimate design, what is going to be. So podmaster's meeting invites and all that. You reserve a big room and have all the stationary ready, and make sure that enough chairs are there, blah, blah, blah, blah, blah. So this is something we need to come up with ahead of the time, which is all the skills that are required, all the components involved. Look at this, and this pod has six components. And the total strength, 26 DAVs, 12 testers in this, total 38. And the proposed teams are like one team with six DAVs and three testers, and three teams, five DAV and two testers, and one team, five DAV and three testers. So there's like five teams we are going to form out of these people. And this is all discussed with the podmaster, ahead of the time. This is a tentative. There could be like, there could be many, like eight member teams also, or nine member teams also. There may be only five member team, because that's how people want to group. So that's okay. But you don't want the team to go beyond nine, unless it's really, really an exception, there is no way to split it, which is unlikely. We can probably figure out a way to split it, right? And there is a agenda like what to do and all that, that day. So we have basically a team room and all that, and we have this skill set and the components involved, and every white board. So we actually made four areas, actually five areas, because we need to form five teams, like this. With this information on every board and chairs, there are stickies on that. So we stuck on the stickies like a developer, tester, and scrum master in some certain cases, and we said, okay, there should be four developers, right? So there will be four stickies for developers and three for testers. So so that if it is a developer chair, they sit only in developer chair if they are a developer. This is all like how you manage this, the whole thing, like otherwise it will be much more difficult knowing who is the developer, who is the tester and all that. So then the first manager went and talked about what we are doing and why we are doing, the purpose of the feature teams and all that, which managers were already trained and coached on that, and what their expectation of this, out of this exercise, they say, okay, at the end of this we want to get like five feature teams who can do all this skill, who has all this skill, who can work on all this component, right? Then the product owner talked about what is coming for next one year, okay? Next one year we are going to have these, these, these features in our product area, and this is what I am going to expect you guys to work on. So keep that in mind while you are forming teams, whether you have enough skill set or not, right? So the round one, so the big room like this in the cafeteria we got like a 30, as many people, 30 people or so, I said, okay, all the managers out, scrum masters out in some cases, and also product owners are out, then we asked everyone, okay, are you comfortable now choosing your teams, or are you worried, so you know, yeah, the team, yeah, and the coaches, okay, so I'm there and all the other coaches are there helping me. The managers who can influence, and people are maybe could be scared of, or they don't want to pick up if there, somebody is there, so we don't want to influence too much, so we ask them to leave politely. Then the round one is to, okay, so we got everything set up, please go ahead and take your, pick your chair. So all the 30 people are sitting, standing there, in the middle of the room, said, okay, start, explain everything, go ahead and pick your team. I think we're running out of time, I'll speed up. Okay, what happens? It's a very, it works so nicely because the dynamics between the people works so nicely, so you watch everybody moving around, right? So you want to work with this guy, he's going into that team, right, so you go with him, but you don't want to work with somebody else, you don't want to go with that person, right? All these little things are very difficult for somebody to really manage. If you go and ask, okay, where do you want to work? Which team you want to work? You may not even tell me, right? Here you are just going around. The dynamics works so nicely and all these issues, lot of these issues gets resolved automatically when people move around and choose their team. So we just left like, gave them like 10 minutes or so so that people moved around and finally settled down and some people will be walking around not deciding which team to select and all that. And so finally after 10, 15 minutes, everybody chose his chair and they settled down. So that's what this exercise, that's what is happening here, people are moving around, picking their chairs and all that. Then what happens is, so this is team one, now all teams and the product owner and manager everybody comes. Then there is a board here with the components and list of components and list of skills. So go over, okay, do you guys have all these skills, all this component knowledge? So we basically mark it whether they are very strong, strong, moderate on either the skills or in the component. We mark it for every team, right? And also people will give some information like they say, hey, this is a very junior team or it doesn't have a gender balance, it could be anything, right? They just give all kinds of feedback. This feedback is for the team because team has to perform eventually. They feel, oh yeah, we don't have that skill really. We need to acquire it, right? So we do that and then we just go over each team and mark this. And at the end of this, okay, look at your boards and see what skills you need. You may be strong, very strong in certain area and weak in certain area, it will be difficult. You may choose to be like that and acquire. You're confident that you can acquire that skill, that's great, but if not, you need to negotiate with some other team to get that skill, right? So that's the round two. So this is another representation of some other part. We just use some pictures like a happy face, sad face and flat face. But the same thing as we did here. This one has a less number of skillset and domain. In the round two, what they do basically, they look at, okay, that team has skill I need, but they need to give up something. So you go there and say, hey, can you come to my team? I said, no, no, we need this. Can you give us that skill, right? So that negotiation happens in the round two. And after that, some gap will be filled. As a facilitator, the important thing is to make sure that people are moving around. They're willing to move. Whenever nobody's moving, you want to go and motivate. It's not like a team's goal. It's like the organization goal. If you want your whole part to be successful, not just your team, right? And there will be some neutral people who don't want to, who are not very keen on just working on a particular team and they will move initially. And you want to really applaud. You want to make it a big deal. Oh, see this guy's moving, he's the leader, right? So everybody clapped and other gets motivated. Oh, okay, I don't mind moving now. And there is opportunity also. You want to move, maybe you are leading that team. You are learning new skills. That's a great opportunity. So those are all the different facilitation techniques you may want to use to motivate people to move between the teams. Okay, so same thing going around and taking the feedback. And the round three, last couple of changes, there will be maybe a handful of, not even a handful, maybe a couple of changes like somebody really want to move. And also you want to make sure nobody's really upset. They may not be very happy, but they don't mind. But at the same time, you don't want to leave anybody really upset. So in one of the exercises that happened, one person said, in the third round, I don't want to work in this thing. Because all the other people on the team are like geeks, they're very always working, not really know socialization and that kind of team. And this guy doesn't really want to work there. But if he leaves, that team size will be very small. And that team is okay with it. So then this guy moved to a different team. And it is okay. So that's just one case. And other cases, the podmaster came and gave his assurance that, how to fill the gap to make the people happy. So at the end of the day, I would say majority of the people are really happy. And some of them are okay, right? So about scrum masters. In this whole exercise, scrum masters is a different equation. So scrum masters have two different sets here. One is a full-time scrum master. That means they don't have any secondary role. They're completely scrum masters. So in some parts, scrum masters, they have enough scrum masters to cater to one-to-one. Each team has their own scrum master. When some teams, they don't have enough scrum masters. So one senior scrum master has to take multiple teams. So we use different patterns. In one pattern, we also put the sticky for the scrum master. Scrum master also goes and chooses the team along with the teams. So they also be there and move along with the. It all depends on the team's comfort. If everybody says scrum masters could be part of this exercise, we just added them. Scrum master, okay. So I missed one point here is, scrum master selection process happened prior to this. That means we advertised within the organization, anybody who wants to be a scrum master, apply for it. Then we interviewed all of them. We asked, why do you want to be a scrum master? And all that thing. And finally, we decided about 45 scrum masters are the qualify for the job because they really want to do it for whatever reason. But they need to be looked at as they go, right? And scrum masters, we know who the scrum masters are before this exercise. And the only question was whether they should be part of the whole exercise or not. That was again the comfort of the pod itself. They said, no, no, we don't want scrum masters to be part of this because all scrum masters are managers. Okay. We don't want them to be part of the exercise. So they will be chosen later without, like we don't know like how they are chosen and all that, right? So there are different tactics used. And so, okay, so the full-time scrum masters are in both ways we manage that way. And scrum masters have a dual role. Like a scrum master is a tester, plus scrum master. And scrum master is a developer plus scrum master. In that case, so the original pod design, team design, we know that one of the teams who is going to have this scrum master, there won't be, there will not be additional tester. Because he's also a tester. Right? So those dependencies need to be worked through as they are forming the teams. So we had to do that for one pod like that. So finally we had a team and then we did some team exercises. Finally we got the team feedback, how they liked it after all the teams were formed. So everybody from each team came and said what they liked and all that. Most of the feedback is they really liked the empowerment to choose which team they want to work. Lot of people felt that earlier they didn't have an opportunity to work in certain team or certain areas and now they got opportunity and they really like it. And lot of learning opportunity because now juniors, one team, one example is everybody said one team is very junior team and probably they are going to suffer. But the team said, no, no, no, we can do it. So that team was left alone but that team did very well because they had opportunity to learn now and they really excelled. So you don't know that, right? Only team knows, only individual know how good they are. Not nobody else. Managers said at the end, I did not think about these combinations. The final result, I couldn't have thought about all these combinations but I'm happy with the overall outcome. So those are some of the things it came out at the end. So this is the outcome, some outcome and there is probably more. Already, since we formed this, since we formed this, it's probably six months or more. I did this, I worked on this engagement last year. So we were out of the engagement by October but we formed earlier and then we coached the teams as a future teams with all the joint exercises and all that stuff. Yeah, yeah. And the one good thing is the pilot teams we did, during this exercise, they stuck together. They didn't want to split because they already gelled by then because it took like two months before we did this whole exercise for the airport after the pilot. And they formed as a very strong team which came out of the pilot and they pretty much they stuck with that and only difference is one or two people had to change because they added one more component to it. And these guys didn't have that knowledge. Okay, the post-team formation, we did all the fun activities like team building activities and all that stuff. We wanted to get started quickly. However, the teams actually gel faster when they're formed this way and that's the concept and we saw that in the several teams and it probably is not as easy as I'm saying here because when you are really there and work through a lot of things, get a buy-in from the manager and the product organization and teams itself and even after that coaching and everything could be really challenging but the final outcome, if it is all done right, it's all done well, went well, the final outcome would be you'll get a very good results and you get very good high-performing things. So some of the tips for the successful facilitation like you need to get the buy-in from the influencers, you need to talk to several people about what you're trying to do and see what they think. Otherwise, when you really are in the room, then there could be problems because people start raising issues and it won't go very well, right? It's not like you're forcing them not to talk, it's more like convincing them why it is important. Okay, so these are some of the tips for that. So now we can take probably questions because, you know, we're already over. Okay. So I'm available, I'll be around and till evening and anybody who wants to talk on anything, I'll be happy to answer. And thanks for staying awake. Thank you.