 Joining in on a late Saturday afternoon and on the last day of the conference. I know it's coming out to be really hard to do at home. But yeah, thanks for joining me. I really appreciate that. My name is Zaheer. I have been learning agile since past eight years now. I got this opportunity to drive this agile initiative within my organization. I have got with me Rituparna, my colleague, my friend. The idea today is we plan to share our experience in the next 35 to 40 minutes on what has been our agile initiative at our organization and how it turned out to be a huge change in the initiative for us, I think. So we started our journey in 2005 where the initial part of the journey was to streamline the scrum access processes within our organization and try to pilot some of our projects with some level of distributors and that's how we started our journey. But as we moved ahead and we started partnering with our customers in the large agile transformation initiative, we realized that we actually disrupted the way our roles were there in our system. We actually disrupted the way the particular goals and objectives were there for our particular roles and objectives in our system. What happened then was while the team were enjoying the agile solutions, they really appreciated the way the agile executes. But then somewhere there was conflict between what they were doing on the ground and what the system they wanted us out of the goals and objectives. So that was one of the challenges that we started facing. Other aspect was some of the roles were starting getting, you know, questioned why do we need this particular role. I'm sure you guys have heard of role with multiple times in the conferences. So why do we need a particular role and what is the need for the role in a particular transformation. So the roles, the charter of the people and in terms of how do I move from a pyramid structure to a flat structure or as we call it as a hourglass structure. I'll be touching upon the hourglass structure shortly. So that was the typical challenges that we started facing from the teams and it created a huge impact on the overall HR system that we have in our organization. The other thing which impacted us was the teams were executing in two to four weeks of time frame. What it really required was the kind of a surrounds of the system. So we had a few programs in our organization. The agile was done in a very nice way. We had our own agile setup. We had a very fantastic of collaboration mechanism, the agile flows. But all of them were tailored to the particular business needs of that particular program. So the challenges that we had at hand was that our internal operations system was not tuned. There was no standard way to come up with the standard infrastructure across the organization that would help enable agile. So that was another important impediment that we started facing. Other impediment was, yes, move from the people aspect. Being the service organization as you all would be understanding that we typically are used to in a command or top-down kind of approach where we get to understand a particular task that we're supposed to do and then that's like we don't have an end-to-end business view. And that started creating huge impact in the way we were actually executing. So the mindset change of the people in terms of what do I really need to do to get an end perspective on business value. That was something which was a huge mindset change and that's how we got into the following issues in terms of the people, process and technology. So from the process perspective, agile demands a complete transparency the way we are executing, even though in an outsourced environment what required from the customer side was what was the team doing across the distributed location. It actually required a complete transparency. So what were the kinds of mechanisms that we had to use to ensure that there's a complete transparency in the execution and that one of the aspect was how do I ensure what is the team doing in a real-time manner. So do we have any system, do we have any project management tool because our legacy system or the way we are operating was actually in a confined manner where we have been assigned a particular task to do and that's it. We don't know what's the end-to-end business goal. So that was the process perspective that we are facing just around the surround structures. Again, the way we were actually divided, the matrix organization that we heard something in the morning. So we had our own testing group, we had our own horizontals. What was happening is that each horizontal had their own business objectives. And when we went to the customer, the problem was we are not able to give the holistic picture but we would have our own individual excellence in terms of test automation or test regression suits. Each of them was there in place. But then how do I get a concise view or how to get a holistic view of things. So that was the challenge that we faced as part of our organization change management and that's where we thought that it's not just about changing agile process or implementing agile process, it is actually a huge change management initiative and that's where we went about organization change management framework. What we realized was while we were trying to do a lot of things in terms of bringing about improvements, while we had a lot of pockets of excellences. For instance, in one of our financial services domain, we had this one team which had been doing this for two or three years of time and they had a lot of good practices. But the problem was these pockets of excellences were not getting replicated, not getting replicated in a manner where we could really say that there's a lot of codification which is happening within the organization. And what really was happening on the ground was there was this huge amount of paradigm shift which was happening. So we had the millennial generation which were really saying that we need to do things differently, we need to get skilled differently, we need to get trained differently and it was very, very imperative for the organization to wake up and provide that kind of support to the teams on the ground. So which is where what we say that it's not just about defining this way of working, defining a set of processes, defining a set of tools, whatever. But if you really believe that agile needs to be, as I call it, it's a way of life, if that's the kind of philosophy that you wish to adopt for the people within your organization, you need to do something at a much more deeper level and that's where the entire change management initiative was being looked at. Which obviously looked at some of the various aspects right from the kind of vision and strategy definition that we had, the kind of processes and again as Zahir was mentioning, going beyond saying that, you know, if we adopt Scrum, how do we adopt Scrum? Do we blend in the XP best practices? Do we have Kanban? Do we have Scrumban? But really going on to looking at some of the core business processes within the organization. So how do you look at doing your teaming? How do you look at providing the right kind of infrastructure support to people? So processes for us looked at all of that and given the fact that the heart of this entire transformation was all about people, the people related processes became very, very important. Technology and infrastructure, I think especially for a services organization, which has at worst at least 70% of the teams which would be working at Offshore, which would be a situation even in an agile way of development. So we definitely end up following what we call distributed agile. So if we don't have the ways and means for the team to really do the things on the ground, we were falling, we were, you know, not being fair to the team. So while we would talk about collaboration, while we would talk a lot about one team concept, if we didn't ensure that we had the right mechanisms for the teams to sit together, the teams to actually collaborate, it would be difficult. And the problems rose from, you know, things as simple as saying, okay, make your work visual, and the teams would stand up and say, hey, you know what, I really don't know how to make the work visual. And we'd go and say there, okay, you know what, get a whiteboard, put all your tasks up there, you know, draw your various station, put your various cards and whatever other impediments, put your impediment boards up over there on the floor. And we got very interesting responses from the teams and responses as basic as saying, well, yeah, I ordered for a whiteboard, but it still hasn't come, which I think are some of the blessings of being in a large organization. So those were some of the things from a core tools and infrastructural perspective that we were stymied by. Of course, also from the way we were really managing the projects, because till date, we were into more of the waterfall way of project management. The project management system that we had was more tuned towards waterfall. We didn't even have a project management system which could get quickly turned around to suit or to adapt to an agile way of working. Communication and stakeholder relationship. Communication at a team level, communication at a leadership level, communication at an organization level. As I mentioned by saying, there were a lot of pockets of excellences. When we looked at the entire, you know, agile journey, what we realized is that there was one team in Hyderabad, possibly who were doing a great stuff. There was no way that the rest of the team which is sitting in Bangalore or some other team which is sitting, let's say in Cochin, had an idea about what they were doing. So focusing on that and as well as taking this entire concept about this new philosophy, about this new way of working to the senior leadership became equally important, because as far as a lot of times the feeling was, okay, this is something which the client is looking for, another SDLC methodology, just go ahead and do it. What's the change that you're actually wanting to try? So communicating to the right stakeholders became very, very important. The next three things and the reason that I've got them all together is all about handling the change as far as people are concerned, because we were really talking about getting people to operate in a different function, from a technical perspective, from a behavioral perspective, from the way they were actually working in the teams, and that's where performance management comes and plays a very important role and so he will talk a little bit about it, because what we were telling the teams is that, you know, you need to collaborate, you need to work as one team, you need to look at the team goals. However, what we were doing is still focusing on individual excellence. So all the performance management systems that we had were driven to identify who is the best performer in the team. So there was a huge amount of dissonance in terms of what we were trying to say at a philosophical level and what was actually happening on the ground. So these were some of the elements that we really looked at from an entire organization change management perspective and what we said and what we took a call of a couple of years back is that this is what we will actively work towards ensuring we are able to provide to the teams on the ground. It may not happen on day one, we would have to take baby steps because this was a change which we were trying to drive in a one lakh people large organization where a lot of work was still happening in the traditional manner. So you had to ensure that you were still, you know, you didn't create a microcosm within an entire ecosystem but there had to be a gelling of the way, so gelling of the way of working between traditional and non-traditional so to speak, but we couldn't afford to have the traditional ways of working be imposed upon the so-called non-traditional ways. I talked a little bit about the vision and strategy and I think what really helped us was a call taken at the senior management level that there would be specific investments on a people process and technology development. Because something which I have typically seen is that, you know, when you typically talk about agile, the belief of a lot of people is, oh, we'll get some people trained and we are agile. Oh, people have gone on a one-day training, two-day training and they are able to do the things on the ground. So it was very important to ensure that you took, you had enough amount of investments both from a time, from a financial perspective around all of these three areas. From a people enablement perspective and when I typically talk about skill building, I think the first thing what we realized was that there would have to be a lot of unlearning and then relearning. So while there was a lot of basic level information which was provided in terms of what is this philosophy all about, you know, what are the various ceremonies that you should look at, what are the things that make a difference. What was very important to ensure that various roles within the organization or within an agile team were enabled in terms of what's the kind of performance that you need to have, what is the role that you're expected to play. So as a team member, if you're expected to be a self-organizing team member, what is it that you need to do? If you're expected to collaborate, what does that mean? As a scrum master, how do you behave? Because one of the things that we typically talk about is that you're not a project manager. You don't put your project manager hat on the head and a lot of times we actually go ahead and tell people that a project manager may not be the best scrum master because you have the same command and control philosophy flowing through the moment you think of a project management, you know, where the project management hat. So as a scrum master, how do you need to behave differently? Yeah. That's a very interesting question. I think it's been tough. It's been very, very tough, especially getting the senior leadership on board. So we do a lot of the knowledge sharing sessions. Thankfully, you know, our leader, that's Mr. Kure and he himself, is a great believer. So we try and use a little bit of his shoulders to pass on some of the messages. He will talk a little bit about the kind of gamification that we've done to make things fun, but especially for the senior leadership, it's a consistent messaging that we need to give to them. We have, I think... We started seeing the benefits when the customer who shows the initiative. The leadership started seeing the customers that are benefiting out of the plan. And then really, because I went for that, also what happened was that we internally within Wipro have our initiative within, there are some of the systems or applications that we need to develop within for the internal people to consume. And we started developing that using Agile. For example, if I look into some simple example of I wanted to have a particular approval for my team members travel, I can do want to go on my mobile application. So some of the internal applications that we developed was using Agile and we started prioritizing things and actually the management started realizing the benefits. So it was not a one-day or one-day training kind of a thing, but it was a journey for us with respect to senior management. We have our internal IT team. That's about 500 people on IT team. So a lot of the kind of experimentation, as Linda was mentioning, we did some of them within the IT team itself and those are cases that we then can take back to the senior management. So I think that helped. But yes, it's been a challenge because for people who are used to thinking in a different way or used to thinking in a fairly traditional manner for them to step away and step back, it's definitely a challenge. So business finance is typically, it was important for us to get the business finance teams on the ground on our end because of the entire contracts and the contract negotiation process which we typically go through whenever we are trying to work on an Agile deal because what we have realized is a lot of the time, the kind of tradition that we have, especially in IT services, is that you know, get into fixed bid deals, fixed price things, which is what people are very attuned to working in and you have the same old waterfallish contracts if I can use such a term, which you try and sort of impose on an Agile project. So it was very important to get the business finance team on the ground on our side saying that this is how things are going to be happening differently. So these are the risks. So your risks are really different from what you were looking at earlier as well as from the business development perspective for them to understand what this beast was all about. Otherwise they would go ahead and make, you know, all kinds of commitments which is not that they don't do that till now. Yeah, actually the way we started focusing here because some of our customers were on the last transformation journey and what happened is that the vendor manages at the customer side started spinning the language of Agile when they came to contracting and it became very necessary for us, for the teams and the financial and the business development team to understand the contracting terms when they are moving to Agile because it was all for them. It's a fixed price kind of contracting and all because that's something they were used to and how did they go away with that. Because as the customer was increasing their maturity in Agile it became necessary for them to understand what they were speaking about. So that means contracts would also revise on time? Yes, in fact, yes. And there is one more role if I can add on. So there is a role that you are talking about Agile coach role. Yes, so when we started this journey we did have external coaches and there was a point of time when we realized that yes the coaches did bring us to some level of maturity but then how do we achieve the sustainability of the teams? Because unless we achieve that then there is no real benefit that we are achieving out of the coach that we got from the external world. So what we started doing is we started studying or incubating the coaches within our organization because there would be some practitioners who would like to get into the role of the coaches and then we came up with a coaching program and an entire coaching cookbook that we had. So those guys, once the external coaches are out they can take up the role and sustain the teams. So they could be within the part of the organization part of the team who can take up the role. So this was one of the critical things that we had to take up. And you will see the term which is mentioned over there is Agile Coach Stroke Manager. And that is again a part of the entire change management philosophy because what we realized is when we go and tell a person who is typically let's say a delivery manager then what you need to work is more of Agile Coach and the first reaction that we get back is hey, hold on, I'm a manager. Why are you changing my designation? So there's a lot of resistance which comes from the way people perceive their role and people perceive their so-called relevance within the entire structure. So I think those are some of the learnings that we've had and one of the most, sorry, yes. So what we have, and here we'll talk a little bit about how the entire structuring happens, what we are very clear is in terms of who is responsible for the people management aspect of the team. So we've tried to ensure that we don't set the wrong precedences because the usual tendency is that there'll be a scrum team who'll have a scrum master and the scrum master is the manager within the team and that is something which we go ahead and ensure. We almost go on the border of fanaticism around it saying that your scrum master is not the person who manages the rest of the team, of course. That puts a lot of pressure onto the people management perspective but those are some of the things that we've tried to institutionalize. I think this is something on which I'll take the next two minutes is to really put together a program of ensuring that behaviors get changed and once again the entire aspect of behavioral change does not happen overnight. So I'll take your liberty and share one joke. One of the things that we typically talk about is that how do you be a better servant leader? So I was having this discussion with some of the senior managers within the team, within a particular account and I was telling that you need to embrace servant leadership and after about two minutes of talking I saw this gentleman's face and he was a fair gentleman by the way and it had gotten absolutely red. So I said, you know, you seem a little bit agitated. Is there a problem? So he said that, you know, why are you calling my team servants? They're not my servants. This is not expected of you, Ritu. So I said, well, I am not really saying that your team, you know, I'm not calling your team my servants but I didn't even have to finish my words and you got even more agitated saying that, you know, do you mean I'm their servant? So that's the kind of, you know, that's the kind of reactions that happen on the ground. So in fact, we've even got suggestions from people saying that, you know, why are you calling it a servant leader? You should change that term. The term servant is not a very nice term to use. So those are all of the things that we would see on the ground from a so-called leadership layer if I have to use that kind of a term. But for our organization, especially being in services, what was also important was that teams had to undergo a change because this was a team where people were very used to working in a command and control model. This was a team which was very used to, you know, youngsters coming in and somebody telling them, okay, this is what you need to do. These are your tasks for tomorrow. And we're now telling people that, hey, you know what? You need to self-organize. You need to be a self-directed team, which is very easy for us to say, but unless we give people the right kind of training, the right kind of enablement, the right kind of confidence, it's very difficult for them to say, you know, I'm going to do, I'm going to be the master or the mistress of my own destiny. So those were some of the things that we focused on. I feel like a certificate of communication. What people typically say, you know, ask me, that you mean we should talk like you, we should talk loudly, we should talk brashly. So there's a lot, there's a difference which people don't need to understand, that when we talk about a certificate of communication, it's all about standing up and saying, Mr. Product Owner, I don't agree with you. Or Mr. Scrum Master, as a team, this is what we believe we can do. This is an impediment. Please help us resolve this particular impediment. No, we cannot do it. We, in fact, have sessions which we do for teams, which is in terms of how do you say no to your Scrum Master, Coach, Product Owner, whoever it might be. This was a very challenging aspect for us because being in the service company and working with multiple partners for the customer, we had to be really assertive in our communication because otherwise it's going to be a huge challenge for us. Sir, if communication could be a roadblock in terms of better partnership? Exactly, if we hit that. Because what happened was that when we were on this journey, there were some of our partners who were not in Ajay. They were just beginning to work. There were some of our customers who were matchy or there were some of our customers who were on the journey. There were some of the customers who had just heard Ajay's buzzword. So there were different kinds of challenges based on the different kind of engagement that they were doing. So it was not an overnight kind of thing. So it's like for some of the customers who are really mature in Ajay, they just want us to do a prescribed way of Ajay that they have been doing, but then we have to challenge them. There are some of the customers who are on the journey and they really seek our support in terms of our experience with some of the engagements and how we go about it. So it's a mutual callable kind of thing. I think what was very important was to stand up and tell about the impediments very openly and a lot of times in the initial days as coaches we ended up doing those things even with the customers. So I'll give you one example. We were working with this, we still do, with this financial services client of ours based in the East Coast. And the team on the ground and they were just, they were on the agile journey and the team on the ground after a couple of weeks, I heard a lot of murmurs on the floor saying that this is just something which is horrible. So I was probing that what's so bad about it. It was very interesting. They said that, hey, you know what? You guys have told that we need to attend all of the ceremonies. So this was a distributed team. So we need to attend all of the ceremonies. We need to get into doing the daily stand-ups and XYZs. The client has and client fixes these up as per their time convenience. So we end up staying back in India till about 10, 30, 11 in the night and next day our manager expects that we be back on the floor at nine o'clock. So we did two things in that case. First, have an internal communication with our leaders saying that, you know, whoever is the manager who says that teams have to be here at nine o'clock, you need to change that. You need to ensure that teams are able to work till 11.30. So if they're working till 11.30, you need to ensure that they are provided with the right kind of infrastructure, right from the transportation, the food, whatever you have. And then when the client came in, incidentally the client was coming back, came back to India. I think they visited some two weeks after our conversation. We stood up in a meeting and we said, you know what, we are having a problem. We are not, we haven't defined, we haven't been able to define a core hour of overlap which is conducive to both parties. And that's when the client leadership stood up and said, you know, good point. We'll start our day at eight o'clock. You ensure that you stay back till about nine and we'll make this work. So a lot of times having the conviction to stand up and tell about those impediments so that those get removed. And that's the entire change which we are trying to also try on the ground. I think we've been a little bit better than earlier, but again, not the end of the road. Yeah, so we talk a lot about the cross-scaling and multi-scaling and we have been thinking on how do we achieve that? Because it is easier to say, but how do we achieve that? And what we realized is that any new influence in the organization, somebody from coming from the college, right from out from the college, the focus in the induction plan was based on the technology, but they were not exposed to something like how do I achieve a continuous increase in CICD kind of a thing? How do I go about using a two-cumber and jack-in-frame thing? So, you know, that was the kind of thing which we realized and what we did was as part of the induction plan, we gave them an introduction about what is this continuous integration, what are those engineering practices that you need to learn and understand right from the beginning. So what happens is that there's just stages and they, as they move on, apart from understanding the domain, the technologies, some of the engineering aspects are there right, inhibited right from the beginning. So that was the first thing that we did as part of cross-killing. Other thing was, I test upon the hourglass. Any idea what is the hourglass indicates? Any other, I guess, sorry? Team structure. Right, yeah. So initially, as Ritu was mentioning, we were completely a pyramid structure and the middle management was really top-heavy. Now, yes, those middle management had moved themselves into a pure play-operational kind of a work, but then as we moved into agile, their roles become relevant. But then at the same time, what we realized, it was a years of experience that they were into. They had amazing years, domain experience. They had really good technical skills. What we did was, the hourglass structure is actually, if I squeeze a pyramid, my middle layer, it would either go up or it would come down. So when those roles started becoming redundant, what happened was that some of those people were actually able to take up some of the domain skills, were actually able to become domain consultants or they were able to take up some of the architecture power. Or if I had a large scaling engagement, they were able to do a program across my releases. So, you know, those were the kind of things which they were able to do. Some of the teams preferred to be at the team level doing the things at the ground. It could be a scrum master, it could be a technical person. So, that's where we call about this hourglass structure, where they had one core skill, but then they were able to move upwards or downwards because they started their carriers as engineers, they started their carriers as domain consultants, and then they had, because of the way the Wipro or any other service companies are aligned, what happens is that in order to move up the carrier chain, they moved into management group, but then they got a chance to again get back. So that's what the concept of hourglass is all about. We have a huge market resistance. The first thing which we heard when we told people on the ground in terms of, you know, don't identify yourself as a developer. Don't identify yourself as a tester or a BA. You're a team member. And I still come to this lady who came up to me and said that I will be an architect for the hell I don't know about. So that's a lot of resistance. I think what happens is somewhere over the cycles or the delivery cycles, which typically it takes off three to four months period for somebody from becoming a completely disbeliever and a huge amount of resistance to gradually move because especially for our organization or services organization, the things that we talk to people very, you know, can be emphasized is upon the kind of technical skill building that is possible for them to do. So, you know, you are typical from I to T to buy. You talk about that kind of skill building. Second is a lot of buying can be facing that way that we are able to do. In your typical pyramid structure, and I don't know if that is relevant within your organization, but I know it's relevant in our organization. So you have this whole layer of what it would be if you were to call such a certain thing. And then you have the layers. You end up talking to the customer. And this, and over here, you have the junior most person being forced to talk to the customer for at least 50 minutes a day because your product order is there in your BSM. What helped us, I think, was a huge amount of support that we were able to give the teams on the ground in terms of getting themselves re-skilled and re-oriented. But yes, I mean, in the initial days, it's typically people say that, oh, you're in a giant project. It's like people were not appreciating the fact that, okay, the title as a program manager or a delivery manager or a project manager is being diluted. Right, but then it started enjoying the... Yeah, in fact... In fact, what happened is that some of the people whom I have been working closely with, they actually started enjoying once they moved into the top role because they were interfacing closely with the business. They were interfacing closely with the technical guys. And that's how the value started coming up. Otherwise, they were pure transactional kind of doing work and that was not actually helping them. So, in the interest of the... Sorry, I have a 10 minutes, so I'll quickly... I just want to ask you one thing. The aglas means that it was like the vision of what you call the executive leadership and the scum teams, or it is more role-based like scum teams and okay, the product owner and... Yeah, so we had this huge middle layer. Exactly, what was the middle management falls into? So, either it depends on their... We left it to them, whether they want to move or not. It's important. We have a question. When Agile is initially implemented and there is change in roles, so I do understand how the department will talk to business directly for everyone, with the new guy and the old guy. So that gives encouragement and newness. But after a while, how do you keep these employees motivated? Because in other structures, you have like in the Indian context at least, every two or three years person is assuming that I will move up and then up and lead and super lead and someone... Well, I don't have much time, but I will take it offline. I will cover it slightly here and then probably offline. We did face this issue here. So, in the interest of the time, do I need to play some game here or... Do you guys want to play some game here? Some of our current generation, as I call it, they got fed up sitting in the classroom for two days and understanding what is crumb and what is... So what we did was, they can, at their own free time, play some of these games and understand the concept. It's not coming up. Small things that you try to inject a little bit of fun and learning is understanding what is the reason for the millennial generation and it's even more true for fun that is like us. Right. Because that kind of element put this learning at a lot of senior leadership meet or so-called senior management meet you would have these kind of feedback. In fact, we also have a lot of road shows during the lunchtime so that people come and understand this and play it. So this is one of the games, so I do want you guys to try this out. The rearrange the image is to solve the puzzle. So what happens is that it's actually online. I try to get it offline here. So once the team completes, a particular person completes, it starts competing with other people. So how does I complete faster? It actually... This is the simplest of the game that I'm showing you here. There's one here. Sorry. Okay. What we also did, as much as this is all about rearranging the size, I don't know. Which one do you want me to work with? Which one do you want me to work with? Just trying to double click on any side. So if you double click on a slide, double click on a type, the entire thing pops up. What is this thing all about? So that's how we try to inject a bit of fun, a bit of learning into those things. Yeah. Other thing is some other games, we also had a Konbaniya Karapati kind of a game. It allows a person to go through a series of... Yeah. So in fact, we had to challenge those at that point of time. But I remember we had to see a little bit and we had some of our general managers and DPs and we called them into the booth and we said, hey, you know what, play the game and your rest of the team is going to watch what is that something to do. And for everything, they were able to do correctly or incorrectly. There was a lot of engagement which happened on the ground. I think those are things which have been important in sort of getting us on to the transformation. We also had a scenario-based game where we were performing the role of a scrum master or a product owner as a team member. As a scenario, I get a particular scenario of what would be the best thing that I would be doing in that particular situation. So that whole scenario-based game that we also developed, that's the Concurse that I'm talking about. It's within our Vipro intranet for our employees. I don't mind if you guys can try this. I don't want to open. But in fact, what we do is a lot of the times for a lot of our client engagements, these are shared and these are put in the network as well. So the teams can do it jointly. So it's not as if only Vipro teams have accesses. This game is a double pile of freshers, college class out, and integrated analysis. This happened quickly now. Okay. So candidate growth, some of the people, I think someone asked me a question about candidate growth here. What we had was we had a typical this kind of structure, the pyramid structure. What we are trying to move is we are trying to move towards this kind of big structure that we have a core scrum team and support structure in terms of my release manager program as it would be based on the scaling that we have and the support team that architects do. So this is the kind of structure that we have. I think I can discuss in detail probably often because of the interest of the time I'm asking. What we have done and I think that's been a bold step definitely for our organization. The entire career framework has been redefined for people in agile projects. So there's a very clear roadmap in case you want to be a career agile person. What is the way that you go forward on it? As well as if you want to still ensure that you have a degree of fungibility that you might want to work in an agile project tomorrow or in a non-agile additional project because in Wipro we have all kinds of work which we do right from application development infrastructure maintenance and so on and so forth. So how do you ensure that you still have the fungibility and yet if you want to believe that this is what I want to do and this is the way I want to develop my career further we've now offered people that kind of a roadmap as well and that's something which helps build a lot of encouragement within the teams because now they know it's not this skill and tomorrow it's going to get wasted on non-agile. In fact, I shared one of the challenges in the first slide saying that people are not clear about the chart on the books not like this. In fact, we have now put it in our system where we have a career hub in terms of agile where in what is a particular role supposed to do and what is the next level career map from the agile team perspective. So that is something which we have in place now. Communication part of Agile Day in 2014 we had Tatakad Varma also representing us and talking about scaling Agile. So this is the way we actually encourage and make people understand what Agile is all about within our organization. We do have a newsletter coming out which is a fortnightly monthly quarterly based on coming from the senior management some of our existing programs sharing their case studies sharing their experiences in the form of recognizing people as part of this was the we have one of our speaker at the conference talking about the enterprise scale and how is it impacting people. So it's the way we are trying to communicate understand you know make people understand what Agile is all about it has been a challenge for us to just go by training it's about how do we try to communicate across the organization. I think training is only the first part of the engagement. Looking at these kind of other things build on that a lot better so you know the one gentleman who's speaking over here on the left hand side he's a gentleman who manages the delivery for one of our business units overall so he has about what five or six thousand people that end up working for him and he ends up talking to people on the floors within sessions talking about what are the kind of challenges from a career perspective or the kind of difference that it makes and those are things which help bring down a lot of the resistance that we had seen in the organization. Talking about Agile and encouraging is something that we have been doing. It was one of the cases that we shared about how they went about things. Sharing some of the best of the experience where they might even failed it's not about just sharing something which we had succeeded about. Did you put up a system So other aspect is the technology part you know as Ritu was talking about you know we want it it's done can I take another one minute Thanks sir If you can Right, so from a technology perspective you know I spoke about the challenges in terms of having a complete transparency across our customers across our partners so one of the things that we came upon was cloud based CLM so cloud based CLM which help us the underlying platform could be RTC or it could be a TFS or it could be anything but the cloud CLM would actually help us come up with our engineering practices and it would help us having complete transparency across the partners and across our customers so if a customer is new to Agile and they don't have any AL in tool in place we give them as a free of cost that's how we want to collaborate with them that's one of the examples I can take off this offline because there are a lot of things which I can talk about here but then he talks standing at me right now with that, thanks a lot guys I just wanted to add one last part is that for us you know this is the change management journey in my mind is just the initial days this is something that every day we learn something new we try something new it's almost as if we are experimenting earlier we were experimenting with an individual team levels we have now gained enough amount of experiences around some of the areas where we are now trying codification at an organization level so that's a little bit about what we are doing just to end with the shadow in Pune next year if anybody wants to be a speaker please come back to me thank you