 My best to keep my attention out here because I'm a hardened friend of Cricket, so I'm sure you guys will be facing the same. Thanks for joining in this session. My name is Zaheer. I have got the opportunity to drive this large change management initiative within Wipro, along with Ritu. I've got my colleague Ritu here. So in next 35 to 40 minutes, what we plan to do is we plan to share our experience on this huge agile change management initiative. More from a service company perspective and the journey that we had gone through. That's a quick update over ourselves. So we started our journey in 2005, 2006 time frame, where the core contention was to streamline the SCRUM and the XP processes, pilot some of the projects in agile using those practices with some flavor of distributed agile. So that was the very humble beginning that we had. But as we started partnering with some of our customers in this huge agile transformation, we realized that it was a huge disruption in our ecosystem. What we realized was that while the teams were enjoying the agile execution on the ground, they were having the appreciation of the way agile was executed, the problem started when there was a conflict of interest in what they were doing on the ground level and what was the charter or the goals and objectives that were defined in the system for them. So that was the first conflict of interest that we found. Basically the systems and the goals and objectives were derived to bring in the individual excellence. And as the teams were maturing, it was more about the collaborative approach. And that's where the first HR disruption started for us. The next step was in terms of, as the teams started gaining maturity in agile, they became more self-organized on the ground level. And with the large transformation, the team started challenging some of the rules. The team started challenging the existence of some of the rules. So it became very imperative for us on how do we go about absorbing those roles that we have been having for more than 15, 20 years now? And at the same time, with those roles being challenged, what happened was we typically, from a service company perspective, coming from a pyramid structure, wherein there was a top-down approach, suddenly we started thinking, how do we move into a flat structure and probably into our glass structure, as we call it in Wipro? So those were the challenges that we started facing. Other thing was we had our own pockets of excellence, we had engagements where we were completely mature in agile. We were excellent in driving agile. The teams were empowered, the teams had got the surround structure to get the collaboration that was required at the team level, the kind of infrastructure that required at the team level. The problem we faced there was, how do we broad-based that across the organization? So when we were talking about broad-based in the organization, it was about 100,000 people that we're talking about. So from an individual on a segmented excellence of agile, how do we broad-based across the organization was one of the key challenges for us. So these were the people, process, and technology in the surrounding structure, which was really the point of contention on how do we go about the entire change management at Wipro. Personally for Wipro, for Ritu and me, we were happy that we are facing these challenges that would help us continue with the job for a few more years. So what was very interesting for us is that we were living in an ecosystem, which was almost like two in a box. So we had this huge traditional organization, which we couldn't do away with, even if we wanted to, because we had customers who wanted to engage with us in that manner. We were doing a lot of standardized work, standardized, repeatable work, where we were very clear in terms of what's the kind of objectives that we have, what's the kind of end result that we want to deliver. Customers had very clear ways of working and ways of engagement with us, and they were very happy in that. And then we had the new set of customers, well, really not new, but we had the new breed, if I can use such a term, who were really impacted by the entire change which is happening in the industry today. So whether you talk of SMAC, digital, internet of things, you talk about all of those things, the mantra which customers were coming to us was, you know, we've been happy to engage with you for such a long time, but we are planning on doing things differently. How are you going to be working with us, such that you can align with the kind of pace of change that we are expecting? So for us, what was very important was, within the same ecosystem, we had to almost carve out elements which would suit the new word order without completely going away, without completely disrupting or doing away with the old word order. So we could not say that, you know, the pyramidal structure has no relevance at all, because it still did. We also could not afford to get into a system where we said that everybody is going to follow the new word order because we, being in a services organization, where one of the things that we obviously get measured on is in terms of, you know, how many people are working or from people who are from the services background, you'll understand, you know, the billing of people. Are you on bench or are you on a project, which are, which are norms, which I think are very common in today's industry. So we could not get into a thing saying, we will equip people to work in only one fashion and not give them the chance or the opportunity to move into the other, other world as well. So fungibility was something which we also had to look at when we looked at more of the skills as well as the roles of the people. So when we started driving this entire organizational change, well, we didn't want to use much abuse and much use term called organization change. So we put this entire thing under the banner called enterprise agility. And for us, enterprise agility is very clearly a movement, a change movement which we do across people, process, technology and surround structures so that we have a part of the organization which is able to work in the new world structure, so to speak. So, if you could just go back. So what you would have seen in the slide previously is that there are various elements which we looked at right from the way we derive our overall strategy to the way we set up teams, to the way we communicate with people, to the way we really treat our human resources. Because this was a time when we were faced with very unique and very relevant questions for people in the team. So the previous speaker was touching upon some of those things as well, which she might have faced in a single project. But these were things which we are now facing across almost all our projects who are working in this new method. So some of these questions were typically from why on earth should I work in this kind of a model where there is so much stress on a daily basis, whereas if I work on another project, I really don't need to bother for the entire life cycle. Just prior to delivery, I'll ensure that we really get down to work, put night outs, or whatever they call it nowadays, and deliver the result. So the movement from working at defined periods of emergencies, if I can use such a term, to working as per cadence was something which people were questioning. Question was also coming in terms of, because we were now saying that you need to be multi-skilled. You need to be able to do development. You need to be able to do some testing, do scripting. There's this new thing called DevOps. And people would typically come back to us and say, oh, hold on, I'm a developer. What on earth do you mean when you say that I need to learn other skills? Why should I learn other skills? So these were some of the basic questions that people were coming back to us and asking us. Let me pick up performance management. Another very hot topic when we talk to people today. It was a fine balance which we had to draw, because on the one hand, we were telling people that collaboration, forget about your individual excellence. You need to know you are going to put me with a team where maybe the other people aren't as great as me. So despite me putting in my best efforts, the team might still not succeed, which means you're going to be penalizing us. So for us, while in the past 10 years, we would have faced some of these questions in small project or small instances. Today, we are now faced with a situation where we have to do a codification across the organization. Where people can say that I work in an agile project for a retail client, or I work in an agile project for a telecom client, and we all get treated in the same way from a perspective of policies, processes, et cetera. So that was the big challenge which we were facing when we started our journey. And we are no way near finished, I would believe. But that's the entire change that we were faced with when we started this entire thing around enterprise agility. Sure. Right. So we started adopting Agile within our organization in 2005, 2006, as Ahir was mentioning. We are obviously an organization which are driven by our client asks. So even if we believe that this is a project which needs to be done in agile way, we typically would not get too aggressive on that unless the client also shows a similar amount of aggression or passion. But that said, I would say of all the application development and maintenance work which we end up doing, which is in terms of the core, change part of the business for our clients and not the run part of the business. I would say, what about, 35, 40 odd? Yeah. So the way I put it like this, like 2005 and 2006, agile adoption was like a push and a pull. So at that point of time, it was more a pull from the customer. So I would say it was 70% pull from the customer where we got into agile engagement. Today we are in a situation where we can get into a push mode where we can propose customer proactively in terms of agile adoption. So we have various kinds of customers that came to us. It would be a customer who are in the journey of agile transformation who are already mature into agile or who are already on the way to beginning. So it depends on the kind of customer that we need to pitch into. So that would, and at the same time, as she said, I think almost 70% of our AD projects would be today into. So I'll give you some numbers. We have one large client that we work with where around 2000 people are engaged with the client and we are doing work which is core agile, which is not even in terms of, I do some practices of agile. And we also have some clients where, not the entire organization, but maybe a part of their business has decided to adopt this. So we have teams who are maybe as small as 70 or 75 odd. So that's a kind of cross section that we have. We are facing a different kind of a problem today in terms of attrition. So as the teams are increasing their maturity on agile, they are being poached by our competitors. So let me put it a little bit more this thing way. From an overall service company perspective, I think our attrition levels are as similar to, or maybe slightly better in the past couple of quarters as compared to other service providers. Last quarter has been better. If I look at it specifically for agile teams, we see two kind of things. One is usually for agile teams, once people understand and get used to this way of working, they love doing it. They just don't want to get out. So we work with one financial services client where I think there was a peak, a team of around 250, which is right now they have around 200 people working with that particular client for a particular LOB of that client. And that team has been a persistent team for almost the past four years, that's what they claim. So in those cases, we see definitely a greater amount of team cohesion. Where we face challenges, and which is where the thing that we are trying to do becomes really important, is that people love working in this way, but when they have answers, which the organization is not able to address, from the way their careers shape up, from the way their performance gets recognized, from the way their performance gets rewarded, it is when it is, if the organization is not able to address those kind of requirements, that's when attrition in an agile team really starts. So that's the battle which I think we are today. Earlier what had happened is, we did a survey within our teams where all of them are working agile, and the very thing that was coming out of the survey was that once the team has tasted the success of agile, they don't want to come out of agile. But at the same time, what they realized is that yes, they needed some kind of a surround structure, they needed some type of support from the organization to help them gain maturity on agile. And that was something which was a struggle at the initial period where we saw some kind of a high attrition. But as we are now getting into some kind of, providing some kind of support structure, and they are happy working there, and that's where we have seen attrition decrease in the last few quarters. So when I'm talking about a support structure, it could be as simple as, I want to come up with a GAMBA board, or I want to come up with a visual board, and I don't have, it takes me three months to get a whiteboard. I'll give you another example. Since we work in a most, usually we work in distributed teams. So we'll have a couple of people that are on site, and a majority of the teams working from offshore. One basic problem which I don't think anybody realized that when you're working in distributed teams, you need to have very clear hours of overlap, something that we internally call core hours. A lot of teams when they start, they don't have core hours defined, and they end up working in scenarios which are really inhuman. So I had this one person who came back and told me that I just don't want to do this agile, don't even mention the word in front of me. And when we probe further, what we found was very interesting. This person said that, you know, the organization expects that I be at my seat by eight o'clock. Assume I walk in, even if I come in by eight o'clock, I have my breakfast, I'm in my seat by eight 30, because that's when my on-site manager is gonna talk to me and tell me all what has happened with the client. My day goes on. Around six o'clock is when my client wakes up and starts performing a lot of your ceremonies. And you guys, which is basically the change team, you guys come and tell us that you have to be a part of all ceremonies. So I am attending all of your ceremonies till about nine o'clock at night. Then I have to find a transport facility, go home, if I have a wife at home or husband, hopefully they'll have food cooked for me. This person in the discussion was a man. So he said, you know, my wife cooks for me, but I know of my other colleagues who don't have wives. So they have to, at around 11 o'clock at night, literally scout their surroundings for food. This was something which, at a large scale, we had never even appreciated. So we now have policies set within the organization, where from day one, if a project is starting on an agile mode, core hours are defined. There are facilities which are provided to individuals because we have a lot of women in our team and we have to also take care of the safety of the women in the team. So there are specific facilities which are provided to ensure that people are able to reach home at a particular time, whatever has been agreed. If required, the subsequent day, they start work late. So the entire work timing from eight to six has shifted. So some teams say that we'll work from one to nine, some teams have some other hours of working. So those are things which now the organization has accepted, that this is something which is going to happen and you don't have all of the bureaucratic loopholes that you have to run, saying that, hey, you know what? I need some approvals because that's another example of support structure. So this is what he was also talking about, that we have the center of excellence which started as a center of excellence but I think has now moved or merged to being more of a practice center of excellence rather than just a center of excellence. And this is the central team which is driving the entire change within the organization as well as driving the transformation across all of the delivery teams. One of the things that we focus on very, very strongly is from a competency development perspective, our focus has been in terms of unlearning and relearning. So on a core agile perspective, there are a lot of role-based training programs that we run for people, right from our team members who can become scrum masters, agile coaches, managers, et cetera. One of the other things that we realize which is very important for us is it is not only enough that the teams be aware and the teams be in the know-how, people from the other parts of the organization, right from the senior leadership, to the business development teams, to the financial and the business finance teams. They also need to be equally aware of, they might not know all of the integrity but they need to be aware of what's happening as far as this new way of working is concerned and how are things gonna be different. So I'll give you a simple example. Somebody was talking in the morning about teaching agile to sales. One of the things which I have seen teams talk about and literally rail against is that my sales guy has gone and agreed to anything and he came back and told me that my client has said that requirements keep changing and hence we will do agile because I can change requirements at any point of time. So I said, well, that's very interesting. Have your sales guy discussed in terms of, maybe having a definition of ready, having your acceptance criteria as well defined, grooming your backlogs, ensuring a product owner is available. And the guy looked at me with a very sad face and said, what do you think, Ritu? Does that really happen? So it was very important for us that we got those constituents also trained on at least a basic awareness or provide a basic awareness of this new way of working. Otherwise, the entire pressure would come on a team which is already under a kind of a disruption because of this new way of working. Yeah, at the same time, it was while the teams or some of the programs were moving from waterfall to agile, we realized that there was a need to change some of the way we have done our contracts for the SOW because while we started executing in agile, the underlying contracts remained water-polished. So it was very critical for the business finance guys to understand that and revise the contract, the existing programs and that's why we had to train them to agile, make them understand what are the nuances around that. Also one thing which I would like to touch upon is we started with having the scrum master trainings and having two days of external trainings or internal trainings. What we realized was that the two days of training was not helping them to actually perform the role of a scrum master on the ground. So what we did was we did some kind of online simulation on the gaming platform where they actually went through some of the scenario-based questions and queries where they would be actually getting into the scenarios and understand, okay, what would I be doing in this particular scenario? There was nothing right or wrong but what is the most appropriate thing they would be doing in that scenario? So we came up with that kind of a simulation exercises for the scrum masters for the teams in some of the cases, product owners that we are having from our side. And most important, the agile coach while we started our transformation using some of the external agile coaches, what we realized was that they would definitely help us bring maturity at a certain level but then what we needed was to come up with some kind of a sustainability. And at the same time, we realized that if we have somebody from internal organization, they would understand our DNA because we knew what needs to be done and to understand how to do that, we had to understand the DNA of our organization. So that's where we started incubating people as agile coaches from within. That was one of the things. From a, I think with a lot of scrum teams coming up with a lot of people adopting agile, what we have seen is people talk about a lot of cross-killing and multi-skilling and a lot of them do not have the answer of how to go about that. So in our case also, we had our teams, our practices enabling the people into one core skill. It could be a SAP or it could be Java or a J2E or something. So that was a practice level skill that a person was getting into. What was required is how do they adopt two, three, four multiple skills. So there were two aspects. What are the kind of skills that they can adopt apart from the core skill? And the second thing is, we had to bring up an infrastructure around that. So if I had to build a, if I have a Java resource and I want to bring it a continuous delivery pipeline, how do I enable them or make them hands-on using some of the tools to get a CI CD or a virtualization thing in place? So those are the kind of surround structures that we have to build to ensure that they gain the multi-skilling style. Also, if you see on the bottom here, I pressed upon the hourglass. So how did we move from a pyramid structure to hourglass structure? At the beginning, I talked about there were some of the roles which were getting redundant or some of the growth that were getting questioned. So that was primarily from the middle part of the pyramid structure. So what happened was, those people had spent years of experience. They had capability into the domains. They were really experienced into the domains. They had the technology acumen. So if I squeeze the pyramid structure, some of them would get into the SME layer, where they would be domain consultants, where they would be architects, system architects. And some of them would be happy performing the role of a scrum master and so on. So that's how we tried to bring in the pyramid structure into the hourglass structure. And while it's easier said than done, but we required a lot of unlearning, as I would call it, a lot of unlearning for them to go from their typical operations job to move into some of the SME roles where they would be actually interfacing directly with the customer and actually have their end view. And the most important thing was they need to understand what is the customer end goal. And that's where they started getting into the role. The element of skill building or capability development was around behavioral trainings. And there was a huge, that was I think the biggest change which we are still working on because I think that other things are relatively easier because in a technical skill building, I can always tell a person that, you know, you move from I to T to Pi and all those kind of development models and all that is very great. But the entire focus on behavioral development has been something which has been very key to us because what we were expecting people to do on the ground was basically start thinking differently, start acting differently. And I'll share my joke. So I've got this, you know, this is a very nice anecdote which I would like to share with you. I was talking to this one leader in the team and he was incidentally, he was more of a line manager than a leader but I was talking about agile with him and I said that, you know, we really need to start adopting the philosophy of servant leadership. So you have to have servant leadership being displayed in your team. So, and this guy was a very fair chappy so he got very perturbed and I could see it on his face. His face almost started turning red and I said that, is there a problem? So he looked at me and said, well, Ritu, you know, I've always known you to be a fairly rude person but where do you get off calling my team servants? Which I said, well, I'm not calling your team servants and as you can imagine, I couldn't even finish my statement and he erupted saying that, do you mean I am their servant? So, simple terms which we who understand the philosophy believe that it's so simple to understand. It's such a basic, you know, basic philosophy. When you take it to the teams, cultural nuances, you know, ways of working, social mores, whatever you have it, they take things differently. We have very interesting questions which we face from teams. There was one senior architect. She was a senior architect if I recall. So she came up to me one day and said that, I have a problem. So I said, okay, what's your problem? See, she said, you know, my designation, all this while has been senior architect. So I was senior and now you're telling me I'm a team member and somebody even came and said that you should ideally be called a developer. What the hell is happening? So giving people that sense of confidence that the role that you play, the designation that you have, the skills that you own, these are not necessarily all aligned to each other. You might still be having a designation called, I don't know, a developer, but the role that you are playing would be a much, much more complexer role. So having people understand the difference of complexity versus scale was also something which was very important to us from a behavioral perspective. And of course, we have talked about the collaboration and the one team approach. The collaboration approach especially would come very true for us when we looked at the performance management part of it and we'll talk a little bit about that. And Zaheer was mentioning, you know, how we do a lot of more detailed sessions for teams. And one of the things that we focus very heavily on is doing a lot of role plays with teams when we have in-depth training sessions with them. How do you behave as a team member? How do you behave as a Scrum Master? If you are playing a role of a Scrum of Scrum Master, how are you supposed to behave? In case you're playing the role of a PO, what is the expected behavior from you? And those are things which we have seen have become very useful for people to internalize to a degree, I wouldn't say completely internalize, but at least they start appreciating and putting themselves into the shoes of the other person. So we run this very funny simulation that we call Scrum Master from Hell. Yeah, you had a question. A servant leadership is a concept which was coined by Greenleaf. I think it was in the mid-70s, I forget the date, which basically says a leader is a person who is there to serve the team and helps remove the, and I'm not exactly paraphrasing, I'm putting it in my own words, and helps remove the impediments or the obstacles in front of the team to ensure that there is success as far as the team is concerned. Which is what we expect from Scrum Masters and which is where I think the term Scrum Master and servant leadership or the trade servant leadership is almost interwoven, at least in my mind. It is very much interwoven, and whatever readings I do as far as what the industry says, that is something. In fact, we have built a database of all those scenarios that you've experienced from a various engagement from Scrum Master perspective, and that is continuously building, and that helps the new Scrum Masters to get into the simulation mode and understand what they are supposed to do upfront. So that's something which they have improved. Yeah, with respect to gamification, as I said earlier, that the new gen people, the new gen teams that come in fresh from college, they get bored with respect to attending the two days classes, and this is something which you try developing. So these are most of some of the simple games that you've developed. I try to, you want to play one or two games, or you can try it out, yeah? Yeah, so this is one of the puzzles that we're talking about. This helps the team understand the nuances of some of the ceremonies and all. So it talks about rearranging the images to solve the puzzle. So what happens is that if a person is not sure of what this means, if I double click this, it will help them understand what it talks about. You guys want to try this out? Okay, so this is one of the game and we do have this kind of a game. I think you can answer this question. Would you like to answer this question? What is the answer? So it gives the correct answer and also gives the explanation to that. And at the same time, you know, it is a fun thing. From a gamification perspective, the other things which teams, you know, teams also do at their own team level is, you know, there's this coconut ball game, which, and I'm giving you one example from one particular project team. This was a team which has around, in the Bangalore location, they have around eight to 10 scrum teams sitting on one floor. And they have an internal game which they call the coconut ball game, which is you have to, a monkey climbs up the coconut tree based on the number of ceremonies which it performs religiously during the entire sprint and each ceremony and how you perform the ceremony has its number of points. So we've tried to ensure that we incorporate some of the basic principles of gaming as well as gamification into the way we drive this entire change as well. So we also have a Konbane Gakoropathy kind of a game. So these are the games which brings in the basic aspects of agile for the teams who are new entrants. At the same time, as I said, there are simulation games that we have for various roles, which are primarily for the gamification platform as we call it, where the people compete which is on the platform. So that is something which I'm not able to show it here because it's an online game. It has been developed in-house by my team and all the teams were rookies from the college. They worked in agile and I tried to make. But you haven't answered that. These are all for internal use. Please drop us a mail. We can engage into a discussion on this as well. This is nothing very fancy. I want to be completely upfront. This is nothing very fancy. Nothing doesn't have a lot of very high end technology involved or anything. Basic stuff done by people who are just out of college. It was their way of learning coding as well as following some principles of scrum. Exactly, exactly. These are the games developed in some framework, some platform which are very simple to develop. What we often do is we have these kind of semi-road shows during the lunch hour and we have huge canteens. So during the lunch hour, we'll usually put up a screen, have some of this running and give toffees or chocolates as giveaways. Basically engages the entire community and gets because there's still a lot of mind block even within our organization and within the services industry specifically I feel around agile and some of the typical mind blocks are, oh, if I get into agile, I'll have to work a lot harder or pour you, you're into an agile project. So there are a lot of these kinds of misconceptions. So we try to create a lot of enthusiasm around the topic, around the subject, around the new way of working by these things as well. Yeah, so this is something which we've been trying. The reason why I say trying is this especially is a portion where we are still on the journey and we are literally inspecting and adapting almost every quarter or four or five months. So I think we've now come up with the fourth version of a framework from a career progression perspective. So we are, every day we learn something new, we add it back to our knowledge base to try and see how we can further tweak it. The reason that we had to come up with this kind of a career framework was basically people were coming back to us and saying that, you know, let's say I'm a test engineer. If I were in a traditional project, I know exactly how I would go up the ranks. Now that I'm in an agile project, what is it that I do? How do I grow? Because yes, while I might be increasing my skills level, while I might be increasing my knowledge level from a recognition perspective and within our organization, obviously, progressions, the kind of band which you are in or level which you are in within the organization are obviously measures which are fairly well settled and well entrenched. So how do I compare against those? So how does working in this new model ensure that I'm not being left behind? At the same time, while we come from a service organization, what happens is that we align with some of our customers who would be probably adopting the external scaling frameworks. So while we might have our own structure in place, at times what we need to do is we need to align with some of the safe or less and some kind of scaling frameworks that we are seeing now in the market. So we keep on adopting to some of the structures that we want to, which actually helps us in that. So I think we have now come up with a model which has, if I recall, about three or four, three layers, three layers from a work execution perspective, in terms of the various roles, they play three well-defined roles at a team level, at a program level, and at a portfolio level. And from a people management perspective, we've kept it at a bare minimum two. And that has been a huge, huge change for people to adopt and adapt to. So we've seen fairly strong resistance on the ground to be completely frank with you. But it's something that, so we've tweaked around with the model to try and see how we make it more palatable for people so that they don't feel a sense of a loss of worth because in our attempt of building a flatter organization where you don't have so many hierarchies and so many layers and so many added costs, we also had to ensure that we don't take away from what people believe or still believe, makes them valuable or makes them skilled within an organizational context. In short, we aspire to reduce our process complexity and hierarchical complexity by 80%. We stand around 40% to 50%. That's what we aspire to be. It's always good to have high goals. So we want to reduce the process complexity. There is no second thought around that. And we want to achieve this by continuously improving. So as I said, the hierarchical complexity, as we aspire to 80%, we are currently at 30% to 40% reduction. OK, right. So if I were in an agile project, and I'll talk specifically about an agile project, in an agile project, you can be a team member. You can also play the role of a scrum master, which are treated at the same level. Based on the skills that you acquire and the complexity that you're able to address, you can then go ahead and play the role of a scrum of scrum master. Or in case you don't want to build a further career in agile and get into more of the technicalities of it, but you want to be more so-called managerial, you can be a line manager, which will be focused more on doing the people management perspective. From being a scrum of scrum master, you can become an agile program leader or program manager, whichever term we want to use. And from there, it's directly to the senior leadership. As in, not to the business head, but if you're working within an account construct, the leader within the account construct. So whether it's a global client partner or global client partner, whatever might be that designation. So at least they have reduced the hierarchy by three. So it has come down by three. So on the one hand, people look at it, and people believe that, oh, it's only three levels. It'll be very easy for me to climb up three levels. Having said that, while we have reduced the hierarchy, what we have achieved is the transparency across the layers. That's what we want to achieve. And being very clear about the complexity, which people will need to appreciate the level of skills which people will need to acquire to move from one role to another, if I can use such a term. I think we are almost there. Just one quick about piloting across a larger team. We've had this across smaller teams. So what we are now doing is from a performance management perspective, have goals and objectives which are well-defined, which are more quantitative in nature, which are part individual. So it measures the individual performance, part measuring the team performance. And we are experimenting, as I said, with a mechanism where team members, as well as the wrong word to use, team members, irrespective of whether they're internal or external, get a chance to provide a feedback on the person on some of the collaboration aspects of the softer skills. So is the person collaborative XYZ. So that's a three-pronged strategy that we have towards identifying a person's performance throughout the year. What we are also trying to do is get out of the annual appraisal mode, bring it to more of a shorter frequency while we would love to do, maybe fortnightly. We know it's going to be a huge, huge overhead on an organization of our size. So while at team levels, informally, feedback is given at the end of every sprint. And maybe during the retro, so you have a lot of the team mode and the team sensing becomes a kind of an informal measure. What we are trying to do formally is have performance appraisals done, at least for agile teams on a quarterly basis. A little bit about all the communication that we do within our organization. And that's something which we really focus on. And rewards and recognition for us is also for communication strategy also includes a part of the recognition part of it. So we do a lot of our internal sessions where we recognize people. So we run a similar event within our organization, which we call the agile day. And yeah, so you've got something like that up over there. So which is basically a platform where we get the community, the various practitioners to come and talk and share their experiences so that they can learn. We use the social media network as in internally within Wipro for building more of these communities. We've got a very strong knowledge management platform. So we have, we do those sessions. We have a lot of agile coffee, lean agile coffee sessions where basically the practitioners can come together, have a platform where they can share their views and opinions. I think with that we end our session. I don't think we have time for the questions. No, we have two minutes. Two minutes, yeah, any questions? No, we don't believe on the Scrum Master being in any position to impact the performance appraisal or the rating of a team member. So even when, so when we do the, even the kind of a 360 degrees, the Scrum Master does not give a feedback on the team member. But the PO, we would take feedback from the PO, but not from the Scrum Master. So what we expect the line manager to do is to be a part of the various ceremonies. Not all, but a majority of the ceremonies and just observe such that he can get his own inputs about the team as well. But the Scrum Master is not put in a position where he or she has any influence on how a person's career can get shaped except for maybe the skill building part of it. It's more of, it's the PO and the other people in the team. So it's, let's say if the six of us are a team and you're the Scrum Master and he's the PO and I'm a team member, you're not allowed to give a feedback on me, but he can give a feedback on me and I can give a feedback on my other team member in terms of, and it's most of the softer skills, not in terms of, oh, he has worked or he has not worked. Thank you, thank you. There was one question, yeah. Can I take that? And then you can add comments. Yes, I think what we have realized is, and not that I'm saying this for my organization, but whoever attended the previous presentation, there was a picture of an elephant and I am stopping that topic over there. But yeah, within our organization, while people definitely want to do, so even the teams on the ground and the delivery organization as we call it, while they definitely want to do things differently, what they are held back by I think is a degree of lack of expertise and a lack of focus, which is where the central team helps them. We are a big team ourselves growing as well. We hope, if you were to ask me what's your measure of success for Agile, my measure of success for Agile would be within the organization a day when my team or our team has no existence, because that would have meant that we really got the organization into a self-sustaining mode where they are continuously growing, learning, and improving on their own. I'm around 20 people and there are part-time members who are a part of the thing as well. So I think if you touched upon two things, a developer, there might be developer, senior developer, architect, senior architect. So what we try to explain them is the complexity that they will be handling at the team level, at a single team or multiple team level. That makes them understand the integrity of it. So what typically people have been going by is the designation, which is not holding true anymore. It's the scale and the complexity that they are handling. That makes the difference. So the other thing is, yes, there will always be differing levels of skill, even if I say that you're one common role called, let's say, developer for whatever reason. You will have different skills. I think the more important part and the change which is really happening is that earlier, a developer would report into a senior developer who would report into a very senior developer and so on and so forth. Today, all of those structures have been broken or we are trying to break. I wouldn't say completely broken. We are trying to break. As a developer, you are one community, but we recognize different people within this community are at different skill levels because it is not only possible for everybody to be obviously at the same skill level, given the fact that there is a regular attrition and a new population influx that we have within our organization as well. So there will always be different levels of skill within a particular role, but the biggest change which I think has been, the reporting layers which were multiple, that has been broken down. Pardon? Moderation in the sense. Bell curve. Is that what you're referring to? Left to me, I would do away with the bell curve. Left to me, but unfortunately it isn't left to me. So yeah, it is not an easy thing. What we are doing at an organization level is appreciation that, A, the people who are in these kind of projects are likely to be more skilled than people who are in other projects. This is still a hypothesis, so this is nothing broken into stone. So A, maybe some amount of relaxation on what would be the norms of the bell curve and in terms of, again, if you have to look at doing a kind of a stack ranking of people, while earlier stack ranking would have been done only based on individual performance, today it includes other elements. But I don't know whether we will be, maybe that's utopia and we'll never get there, which is in terms of do away with performance appraisals, do away with bell curves and work in an environment where everybody is motivated, is self-organized. I think that's gonna be difficult. I'll be open about it. For us it's still a learning process. So we don't have all the answers, but as I said, every day that goes by we are trying to find out more and more answers and put it back into our learning and go back to the organization asking for different changes and this is an initiative which is driven by the CEO so which definitely helps make the change happen faster. Do not form a part of the delivery organization except for whenever we are coaching a team, we become a part of that structure, otherwise there is a specific other entity because somewhere if you become a part of the standard delivery organization, chances of getting sucked into standard thinking becomes higher. So we are a difference. Yes, thanks so much for listening to us patiently. I hope you enjoyed it.