 impacts the culture, the roots of the organization, right? And anytime changing behaviors, cultures doesn't happen overnight. So that's the whole thing. So what I want to do is kind of jumpstart and get into why we've entered this agile transformation stuff. Spent a little bit of time. I think Shriadri helped me in kind of putting the foundation, I spent some time there. Talk about some challenges and then see where the role for leadership is all about. Any transformation initiative is not going to be successful without an active participation and lead role from leadership, okay? So we'll touch upon that and then hopefully we'll have some time for Q&A. Why we went in for agile? I think time to market was one big thing, right? There were rapid changes that were happening in the market space that we were involved, the technology space that we were involved in, that was going through a traumatic change and we needed to really catch up on that, deliver innovation, but deliver innovation much faster than what we used to do. The other reason why I want to kind of talk about this whole transformation initiative is this transformation took place in a product and a technology space that is pretty unique and is legacy in a way, okay? And not many organizations try to bring in agile into that kind of space. We were working on mainframe legacy kind of products, technology usage, second generation languages, describing different behaviors, thinking how we approach work and stuff like that for all of the stuff. It's a big shift. It's a big, big shift and it has impact at the core of the organization. It has impact on the culture, on the behaviors, on how people work together, collaboration pieces, all of the stuff. And any change that you bring about comes up with its own set of challenges and I think it also brings out opportunities to bring about change, okay? Not only challenges, but I think it also opens up opportunities for change, for positive change. So what are some of the challenges that we faced about? I have kind of, this, can you just tweak that? So I kind of bucketed them into six broad categories, just to ease the conversations. One was around communication and not just communication alone, but also in terms of managing the expectations, okay? One communication from the point of articulating why this huge change, why this big change and how it is going to help the organization as well as the individual part of the organization, right? We did not do a good job at setting that expectation and articulating that big picture of the change. Turn this around a little bit, okay, we'll see. The other one was really, okay, that's okay. The other thing was really around the cultural piece, but more to do with, at the end of the day, it's all about people's business, okay? We talk about engineering, we talk about tools, we talk about technology and all that. At the end of the day, it's individuals for building these products and this technology, right? And if we don't get them engaged and involved in this whole transition, then I think we're gonna have a lot of challenges and we face a lot of challenges around that, having people being part of the change and accepting the change. We were too out of focus. We were too driven by what customers want and why agile for customers, right? And we did not emphasize much around the value proposition for employees. Shishadri touched upon this whole command and control and we talked about in the morning around also why managers, yes, I'm saying not that focused around, I think the whole communication and the reason why we said we're driving, getting into agile is more focused, was more focused with customers and did not bring out the employee value proposition. Now, that's not what I'm saying. I'm saying that there was too much of emphasis only on the customer value proposition and not just on the employee value proposition, right? At the end of the day, like I said, it's people who are bringing the change who are making the change, right? And if you don't get them along with us in the journey, you're not gonna be successful. So that's the reason. I think the end result is to deliver value to the customer but a lot of the change has to happen internally and that's why the employee is coming. The other big piece was around HR. This whole journey around this transformation and stuff like that. We were not effective in carrying HR along with us, okay? To kind of support us in this change. You talk about it from systems, from processes, Shishadri touched upon from a goal-setting perspective, feedback, all of the stuff, right? Those have a critical role to play and we did not carry them along. We touched on a lot in the morning around the rewards, the clinician pieces, motivations, stuff like that. That is a big piece, right? We were traditionally an individually, individualistic kind of driven organization and there was a need for us to drive that whole shift from individual driven to a team kind of culture and how we had the reward and recognition program had to move from an individual driven to a team kind of orientation, right? That was a big challenge that we had. We talked about managers not being involved and stuff like that. Yeah, we had all of those people getting kind of taking a backseat, right? Staying away to the question of what kind of metrics do we use to track or to see what individuals, right? When the managers are not involved, how do they do performance after this? So all of those challenges we could see here, okay? Driving this whole, we were a siloed organization. We were a functionally driven organization, QA, a sustaining teams, a development teams, all of them working in their own siloed in different ways, right? How do we get all of them to work in a collaborative way? That is a big challenge for us. That is a big challenge for us. Like I mentioned, our whole product stack was legacy stuff. Not much of tools really used to drive productivity, right? That is a big change. Other is in terms of what measure was to be used. In the initial period of our transformation, there was a lot of focus around story points to velocities, right? A lot of those. And that drove a lot of wrong behaviors. Drove a lot of wrong behaviors. So that's the other part of it. The other thing that I want to kind of highlight here is really when you talk about a team and a self-sustained team, you need to kind of develop this cross-functional skills and cross-functional roles, the T skills, right? Having people to really adapt and build those things was a big challenge. Why should I move away from what I've been doing for years? The expertise that I have, why should I go and learn something that's not really aligned to where I want to take my career along? So a lot of those stuff, right? And lastly, the whole thing around resistance to adapting to new areas. So these are some of the challenges that we faced. If you look at, I think there are tons of industry surveys that also kind of validated this, right? The management support, the leadership support in this whole transformation, that kind of hinders the success of the transformation. General resistance to change, that's a huge issue. Ability to change culture, okay? That's a big part. You've been hearing this since the morning, I think that's a big, big part of it. It's not so much to do with how you write code, but it's really about how you look at things. And then the availability of skills and link it to the cross-functional roles and cross-functional skills, right? A lot of those things. So what are the areas for leadership to really focus around, right? I've kind of bucketed them around these things. The first one, I think is critical is the communication part of it and how you manage expectations, okay? That's a big piece. The second one is the cultural transformation, right? I hope you're able to hear, okay? The third is around the performance management and reward recognition pieces, okay? Customer engagement and feedback, organization structure and readiness. How are you getting the organization? What kind of structure do you have in the organization? The skills development and all of the stuff, right? That's important. And then we miss out on the engineering excellence piece. That's very, very critical. Just the practices, the ceremonies don't help. At the end of the day, how strong is your engineering practices? That's what really makes the organization really ready to deliver value, right? So for the lack of time, what I'll do is just take two or three of them and kind of go into what you have done to address some of these challenges in the areas and kind of then I'm available. You can have any conversation offline or outside of this. So from a communication and cultural transformation pieces, what have we done, right? We did a lot of road shows to kind of communicate the big picture and get employees to be part of the stage, okay? We also, in each of the sites, we actually built what we called as a site charter, kind of objectives or goals for the development center to kind of work on areas to improve, okay? Based on feedback from the employees. That is one way of getting the employees also be part of this change and have them be involved. We did a lot of town halls around Agile and success that we were seeing from different teams, bringing them, all of them together, rewarding teams, rewarding the changes, improvements that they were bringing about a lot of those stuff, right? And then the big piece around the expectation management. A lot of things around expectation management and so changes in the roles. You talked about job descriptions being changed, right? I think that needed a lot of expectations, management to be done around changes in the job, okay? See, the other pieces around the organization culture, how do we empower teams to be able to take decisions on a day-to-day basis? Okay, how do we get the teams to be self-sufficient so they're not waiting on managers to decide on what they need to do, right? So a lot of that, a lot of focus around that. In the morning, somebody talked about one of the speakers talked about the happiness index, the accomplishment pieces and stuff like that. That's really driving the motivation piece, team motivation, stuff like that, those pieces. The big focus here was really around emphasizing on the cross-functional roles and cross-functional skills, okay? How do you drive the change and how do you build those skills and competencies in the employees? That was a big piece. From an overall organization structure and performance management, we really moved from a global distributed teams, SCUM teams, to co-located fully staffed teams. Now that needed local roles to be created, the pure roles, the SCUM master roles, a lot of those roles had to be locally created and that needed us to staff people, either internally or externally, skill them, train them and stuff like that. A lot of that has been done. Made a lot of changes in the job descriptions. We had to also introduce new jobs, the SCUM master job, the agile core job, the product owner, these were all carrier paths that were created to drive the point that this is not a change that's here for a day, it's there for a long time and there is carrier paths available for individuals to really move who are passionate to do that kind of stuff, right? So, a lot of that. We created a lot of communities, okay? To build collaboration, share knowledge across sites. The pieces are on performance management, Shishadri touched upon earlier also, one of the speakers touched upon, driving this whole shift from an individual focus performance management to a team-driven performance management, right? Not just the goal-setting part of it, but also how do you do performance reviews in a team kind of environment, right? A lot of that was done. Skills development, I talked about from a T skills, cross skills, a lot of that was done. The entire rewards and recognition process, program kind of moved from an individual orientation to a team orientation, right? How do you drive the team culture? Team bonding kind of stuff. So, a lot of that was done. Apart from that, I think the key success is where we were able to move from a waterfall to be able to do daily integration and builds, big shift. We were able to reduce, we talked about time to market, right? We were able to reduce release cycles from 18 months, 24 months to now doing on a regular quarterly kind of basis, right, incremental quarterly basis, right? Shifted the focus from a performance management from an individual ribbon to a team-based goal setting as well as feedback mechanism, right? A lot of that. It is not an event. Transformation is not an event. It's a journey. I think you have to have patience. You have to sustain it, right? You have to sustain it. The big part of it is are you really serious about bringing the cultural shift in the organization? I think a lot of emphasis need to go in on the cultural aspects and I think leadership plays a key role in driving the shift. And I think the other part is how strong is your engineering infrastructure, right? To be able to do these two weeks, four weeks, whatever, weekly releases, right? How strong is that? That part of it. And all of this, I think needs a strong organization chain management to make that happen. It just can't be one, somebody leaving an initiative and driving it. I think it needs to happen across the board. So that's kind of a snapshot of what we did and kind of opened the questions. Yes. Yeah. So simple. If you look at this, I talked about from having an 18 months release and now having the team to be able to really deliver production ready, customer shipable feature functionality in a two weeks, four weeks window requires a strong engineering infrastructure for us to be able to deliver. I think there are a lot of, you can't deliver with defects. So there are quality aspects. How do you start to, so when I talk about engineering excellence, how do you get, so I think in the morning, also somebody touched upon this, having earlier the QA used to get started maybe on the 10th day of that sprint or whatever, the last couple of days of the sprint, right? How do you get testers to be part of it from day one of the sprint, right? How do we have them do, test them and develop? A lot of that practices are brought in. So it's not so much to do with agile. Like I said, it's a shift more to do with, not so much to do with agile or the practices, but more to do with mindset, right? The big focus was really driving that mindset shift, right? And getting them to bring in the technology and the tools, which would help us to deliver faster, okay? With the needed quality. I think those were those are the focus areas. There's so much. Yeah, so agile just fitted into it because if you have to deliver something that's shippable in a four weeks iteration, I have to have the tools. I can't have people just delivering with manual stuff. Yeah, I have a question about the commitments of the team. Earlier we have in the waterfalls, there is a dedicated plan and there's a strict timeline and the team is, they were aware of it. And it is driven by the management actually. Now in the agile, whatever the commitments is made by the team, they commit, okay, in this sprint, I will take these many stories. So during the transition or the transformation from the waterfall to the agile, what are the challenges you faced in terms of commitments of the team? Is are they less committing or you know, how do we challenge the team basically? The leadership team has to challenge the team. So I think initially we saw a lot of slippages and stuff like that, right? What I think we were able to do was allow them to fail, but with the intent that they are going to improve, okay? That is a key, okay? Challenge them and give them the space, okay, to fail, but challenge them that they can improve. At the end of the day, it's not so much to do with, with I'm committing 10 story points, have you delivered 10 story points? It's more to do with how I got the value that I wanted to get from that iteration, right? So as a product owner, as a product manager, am I able to see a value coming out of the sprint? It's not so much to do with, there are four stories that have been signed up, have I delivered those four stories, right? Have I done it with quality? Have I done it where there is quality built into it, right? Those are the aspects that we drove, that we emphasized on. No, I think so, yeah, let me just, let me just make sure that I retract. So there was a emphasis on team-based performance goal setting as well as performance reviews, okay? While there was less emphasis on individual focus goals, okay? That's the way I would put it. Because the individuals go out and do a lot of stuff, okay? That contribute apart from the activities that they do in the sprint, right? So all of those need to also be factored upon. So in this part of the organization that we're talking about, globally it's about 1,000, about 1,100. The India side of it had close to about 280, 290. Now product, pure product, pure product. These are all legacy technology based. That's the reason I said it's a journey, a lot of progress, there is a lot to do, there's a lot to do. And for the cross-functional, you expect the individual also to be cross-functional or the team is cross-functional. So basically I think what our expectation is that the team has enough skills within that group to be able to do what is expected from it, right? So it's building some skills, as well as structuring the team with people coming in from having done some sustaining kind of work to doing having done development to having done testing, right? Do you provide all of that expertise in the team, right? So how do you starve the team with those kind of roles, as well as how do you skill them to be able to be self-sufficient? So there are both the skills part of it as well as the roles. Because in some of the teams, actually we moved away from having dedicated sustaining teams and just having the agile teams doing both feature development and customer support. And that required a big shift, a big shift from in terms of skills and knowledge that is needed for doing the different type of work. So we have now, I think the last year or so we have been now able to get to, we have been very stable in terms of yearly. Now we've started out in the last six, eight months we've started to do now a quarterly incremental releases. We've started to do that globally. At a program level, we've just started to look at SAP, we're just doing that, but we have not. Yes, we've just started to look at that. Yeah, time out, okay. I'm available, so thanks a lot. Hopefully you found this useful. I'm available, any questions, anything I can take it offline. Thanks a lot.