 Hey, so I'm starting off my next session. That's okay. So I'm just starting on time. I've just got 20 minutes. So I just wanted to make sure that I know I just make the most of the time that I have. So my name is Profil. I work with the Walmart Labs in Bangalore. And this is, you know, an experience report for the Agile Transformation Program, which I ran from one of the companies in my previous experience, right? I'm just going to talk about it. I know that the day has been very overwhelming in terms of, you know, scaling Agile and, you know, we've been hearing it from a lot of folks who have gone past, you know, given the presentation. So I think there will be one key take away from my presentation is, you know, I try to keep it very simple. I really didn't put too much of complexity around, you know, you know, in terms of a big scaling model or something of that sort. This was something which, you know, I kind of developed in-house within the company. So, you know, we'll talk about it in a bit, right? So let me just give you a quick agenda. So I'm going to talk about, like, the business context. I mean, the company, what was it into, what it was doing. And then, you know, a little bit background about, like, you know, how the Agile basically was introduced to the company and, you know, how it kind of, you know, the movement started, right? And then we could talk about the problem statement that, why at all, you know, we need to kind of look into the scaling option at all, right? And then, you know, and, you know, evolution of solution kind of, you know, to kind of see what exactly was the solution. I won't say the solution, but, yeah, what was the approach to kind of, you know, solve the problem. And then how we went about doing the implementation for that. And some of the key challenges and some before and after metrics to see, you know, if the program was successful or not, and then we'll conclude, right? So this is about the business context about the company that I was with. So it was in a consumer interface. It's one of the largest companies in the consumer interface. And here the critical success factor was basically innovation, speed, and the UI, right? I mean, these were the critical success factors for the company. And, you know, the company actually had a belief about it's about being more to do, being agile than doing agile. That's what, you know, the company had emphasis on for a long time, right? So how it all began, right? So it started with the grassroots level adoption way back in 2004. That's when, you know, we had Jeff Sutherland coming in and giving a presentation and a talk in the company about, you know, the agile and scrum, and that's where it kind of started getting adopted at a very grassroots level. And later than there was a leadership buy-in. Basically, as you have seen in a lot of other organizations that, you know, why that's important, so I'm not going to re-emphasize on that, that why leadership buy-in is important for scaling agile. And the third point was basically, you know, the show intel. So in bits, in pockets, basically, you know, there was scum teams operating, you know, at their own level, and they were trying to, you know, scale through that point, you know, they're doing more of this show intel kind of a thing, you know, where they're saying that leading by an example, they're saying how it's working for them and how it's being developed. Right? So this was a problem definition, you know, so the problem that we had at least, you know, so I was hitting this, the program for the Bangalore Center, which had about 150 scum teams in it, you know, across five different business units. And, you know, one of my, the charter was to make sure that we do have a proper program in place where you can actually go ahead and, you know, it should be more like a single framework, and it should be basically something which, you know, you can measure on, right? You can see what is the impact on the top line. So sometimes you kind of see that, you know, Agile is all about, like, you know, you're running on a football ground, you know, with the football therein, but, you know, you can't see the goalpost, right? So whether it's really meeting the value, whether it's really helping the teams and the organization, right? So that's what this, the focus was on, on this. So this is how the solution got evolved, you know, basically we thought of a single framework. At that point in time, we had multiple frameworks to kind of go and see, you know, that we could leverage upon, you know, we had, like, SAFE and, you know, some of the other frameworks as well. But, you know, we wanted to see what would fit in with the company's culture, you know, so what is the best framework that would fit in the company's culture, and it should be very lightweight. It shouldn't be too heavy in terms of the processes and, you know, the other, you know, on the other aspect. And then we kind of went about discovering what are the strategic pillars, basically, right? This program should be having, and then how to go about measuring the team's progress. So this is kind of, you know, if you kind of put it in the strategic pillar, right? So basically we had mainly three pillars for this program. One is the HR. The other is the Processing Tools, and the third is the Capability Building, which is what you call as the Learning and Development Team. When some of the companies, they do have the Learning and Development Team, which kind of focuses on the training. Basically the HR was more about, like, you know, defining the role and responsibilities, because, you know, we had folks basically, you know, who were traditionally doing the people management, the manager role, basically, but we had to transform them into the more of a servant leadership skill, basically to be a scrum master. So for that we wanted the HR to interfere and basically, you know, help, do the organization, you know, understanding what exactly the new roles and responsibilities would be and help in the transforming of those responsibilities. Then we had people process, career development, rewards and recognition are related to that and, you know, hiring and onboarding and basically, you know, the culture building. So that was the primary charter for the HR, and then we had the Processing Tools, wherein, you know, we had the one-stop shop process guidance in terms of anything that you might need on agile, on scaling, you know, or basically on scrum, 101, 102 trainings. Everything was available on there in terms of, you know, the governance. So we had one-stop shop basically for anyone to go and look into, you know, any of the information that they might need on agile and scrum. And then basically, you know, one tool to support agile. I mean, there were bits and pockets. Every team was leveraging on, you know, so we had legacy tools as well there and, you know, we wanted to make sure that we bring all the teams on the one single tool so that they speak the same language. They understand what exactly, you know, and we have, you know, one standardized matrix basically to measure them. And then basically build strong agile community. This, I think, is very important, especially when, you know, any of the organization when it's going through the agile transformation, you know, building up the strong agile community because, you know, a lot of show and tell actually are the motivators for the other teams to kind of go and, you know, to even try it out. And then we had the capability building. Basically, you know, this is the training needs analysis, you know, this was basically done by the L&D team. We used to work very closely to understand what is the gap, you know, the skills for the teams and do we need, you know, any external training or the internal trainings for the teams that needs to be done. And, you know, doing any deep-dive masterclasses, basically, right, and creating the agile training portfolio in terms of, you know, for the various levels in the organization, right from the vice presidents to the directors and what level of training they would need and, you know, what level of training the teams would need, right? So that's about coming up with the agile training portfolio. So this is what the agile maturity model, which I'm gonna talk a bit about, like, you know, I'm gonna take some time on this. So this is how the teams were kind of divided, not divided, I would say, the team is measured basically in terms of how they stand in their agile adoption, right? So you could see that, you know, the readiness is like the basic, you know, phase for any of the team, which kind of, you know, they were kind of trying to getting ready with the whole thing to what agile is, what scrum is, you know, getting all the one-on-one basics, right, trying to understand, right? So that's about the whole readiness phase where they're trying to understand what agile and scrum and how that's going to work for the team. The second level is basically the adoption, which is basically, you know, practicing some of those, you know, methods, you know, trying to do the sprint planning and, you know, review and retrospective and daily stand-up, you know, and see how it's going to work with them. And then basically, you know, being more efficient, right? So that was the next stage for the team to kind of, you know, where they're deriving some value, right? So they're doing some velocity, you know, they're doing the TTD and, you know, practicing doing some, you know, XP practices, unit tests, CI and CD, kind of a thing. And the last one was basically the organizational goals are met with the agile practices, right? So that was the ultimate... So how do you kind of measure that, right? Organizational goals are met with the agile practices, but how do you kind of make it happen, right? So we'll come to that in a little later. And as you can see that, you know, the, you know, the training and the coaching basically gets kicked in at a different level where the teams are. Basically, the training kind of helps, you know, more at the readiness and the adoption level and some part to the efficiency level. But the coaching actually would take them to the next step in terms of, you know, how they kind of, you know, understand what, you know, the daily rituals for us are in terms of the scrum, you know, what is that we need to do? What is the sprint planning? What is grooming? You know, and all that. But when they kind of want to step up, like, you know, whether they want to do some, bring in some, you know, extreme programming practices in the team, then basically they need more of a coaching at that point in time, right? So that's where you can see that, you know, the training and the coaching basically fits in at different layers here in their gel or option. You know, the basic is basically it relates to the infrastructure, and then it's become faster. So we're doing, you know, when you try to adopt and when you have a cadence to it, when you kind of define your sprints, right? So it kind of becomes faster, really, cycles. Then you can try to do better with some of those engineering practices, right? You try to make it a little bit more better. You try to deliver more value. And then you kind of, you know, the end goal is basically to deliver software as cheaper as possible and basically, you know, at a very high level, what Agile and HPD model is. So this is the KPI, right? So what I'm saying is it is a very lightweight process. This is what it means. So we had a simple scorecard, right? I mean, we really didn't go through the fancy heavy, heavy, you know. So this is something which we came, which we discussed within the organization and which we came up with. So you can see that, you know, that each team basically has got this set of questions that they need to answer, right, if they are, you know, in the readiness phase or in the adoption phase or in the efficient phase or they are really effective, right? And this was a work-in-progress template, right? So this is very iterative process again because, you know, it was not like, you know, it was one standard template that has been put across and you're not really working with the team to understand. So this has improved over a period of time because, you know, we kind of started with basic and when we felt that, you know, okay, we are there, what next? So we started on these KPIs and, you know, we tried to make it more better, you know, to see, you know, what exactly would work in our context. So, and this was the various color coding for the teams, like, you know, the readiness was in red and, you know, the yellow was basically the adoption and the green was efficient and the purple was, you know, being effective. So this is what the dashboard looks like, right? So when I say for the 150 SCRAM teams, how do I go and measure about doing it? So, you know, so this is what the dashboard looks like. This is where the team kind of gets started, like, you know, you can see from September 2011 to, you know, almost a year, right? So you could see this, how the teams have transformed in their agile maturity model, right? So they started, so a lot of teams kind of started with red and then we had a lot of teams that kind of onboarded in between, right? So the second column that you see, projects onboarded on SAP, which is called as agile and SCRAM adoption program, right? So basically you kind of, you know, work with the team to kind of get this metrics month-over-month to see, you know, how they are progressing in their agile journey, right? I mean, in their maturity model, whether they're doing any better than what they were in the last few months and if they are not, then what is the issue kind of, you know, try to figure out and, you know, if they need help with coaching or they need help with training, right? So that's how you can kind of figure out in terms of, you know, how the teams are basically maturing in the... This kind of gives you an organizational picture as well that, you know, how this is how the organization is kind of moving right from the adoption phase to all the way to the, you know, effective phase. So this is basically the SAP dashboard management view. You know, so this is basically view for the top leaders to kind of, you know, make sure that, you know, where the teams are. So this was being reviewed every quarterly in their quarterly business review meetings. Basically, this is the slide that kind of used to go in terms of where do we stand today, how many teams are actually, you know... So we all speak the same language because we know what green and, you know, what purple and what yellow means. So we all speak the same terms and we understand, you know, how many teams are needed, how many teams do need help to kind of, you know, move to the next stage. So this is the before and the after matrix, basically a matrix rather. So this is, you know, the August 2011 when we started kind of, you know, we had, like, you know, five teams which were, you know, in the effective phase and, you know, the two were being efficient and, you know, we had, like, 15 teams just getting starting to adopt and then, you know, we had few teams which were basically, you know, so 15th is the readiness and, you know, six were in the adoption phase, right? So these are the teams that have transformed over a period of time, you know, in some way, if you look, there are more teams of, you know, in their option journey and, you know, then you had the, you know, the other teams, few teams which actually moved. So this was a difficult move, basically, you know, moving the team from green to purple kind of takes some time and it needs a lot of mentoring and a lot of times, you know, the success factors for the team doesn't really mean that, you know, the team is being agile or not because there are other factors which do drive, you know, the key business decisions that are being done and, you know, how the business is, you know, which teams you are basically measuring. For example, if it's a consumer phasing team, then, you know, it's easier to measure but what about the platform teams, right? So they kind of, you know, are more about services. They kind of give services to the other team. How do you kind of measure them in terms of whether they are really being effective or not? But at a high level, this is the before and the after view of the, you know, of the program. So what are the key challenges? I mean, at least to the time, you know, I've seen that there are very frequent organizational changes. So what I mean is, you know, there were a lot of changes in terms of the team structures. Even for that matter, you know, the business units, you know, where, like, you know, the shuffling happened and, you know, people had to move. So that kind of really made hard to kind of, you know, stick to the one team and to when, like, for example, you started with one team and then you end up realizing that, you know, the team doesn't exist anymore, right? I mean, you know, because, you know, they have some organization changes that went through and, you know, the team doesn't exist anymore and it has been divided into some sub-teams. Then how do I go back and, you know, correct my metrics in terms of a few people here and a few people in the other team, right? So, and the other challenge was basically the preconceived notion on agile because, as I said, the actual adoption started way back in 2004 and, you know, they had waves wherein, you know, the teams have tried it and it didn't work. So, you know, when you go and talk about people about agile, they say, yeah, I know it and, you know, we have done that before, you know, it's not new to us. So that was really difficult, kind of, you know, to get them out of that mindset, right? To say that, you know, being there, done that, there's nothing new that you're going to help us with this. So, especially for this preconceived notion on agile, what really helped in this program was about the whole thing about the show until and, you know, we'll come to that in the next slide, you know, what exactly we did to kind of, you know, to make it more effective. And then, basically, the metric collection for 100-plus CRUM teams. So that was a nightmare, right? I mean, going and getting the, you know, the metrics from 150 CRUM teams out there was a kind of a nightmare, you know, you have to make sure that you do that for every month-over-month without fail to see, you know, how the teams are progressing. So these were the kind of enablers, you know, when I say, building strong community to promote show and tell through, so when I say show and tell, one was about the lightning talks. So the lightning talks were, like, you know, not, like, too detailed, and it was, like, 15, 20 minutes or maximum 30 minutes talk, right? Where the people would come and, you know, generally, you know, we had, like, you know, architects coming and talking about what helped them to when they kind of moved from, you know, from a legacy system into, like, you know, on a CI CD model, right? So it's not just about, like, you know, hearing stories about these things, the work, and, you know, but it's more about, like, a team kind of showing them, you know, this is what it was, and, you know, when an architect, and I'm sure that, you know, there are a bunch of engineers actually who needs to go and actually do this, right? So, or, you know, implement this, or, you know, follow this, right? So, and, you know, the engineers do have their own mindset saying that, you know, yeah, this is all theory, right? I mean, we have read that in all theory, but does it really work, right? So these lightning talks definitely helped us on the same page where, you know, kind of, you know, do that in the organization when you come, when you have some success story to talk about, right? It could be from an architect, or it could be from a product owner, or it could be from a product manager, or a scrum master, right? So that is something that you kind of keep looking for in terms of, you know, who has got a success story to tell, because that has got the maximum impact, because a lot of times you hear that, you know, yeah, yeah, but in our organization, this will not work, right? I mean, it might work somewhere else, but, you know, we, it won't work for us, right? So no, you're wrong, you know, it is working for you in the same organization, right? So I'm sure there might be a little bit more different dynamics, but, you know, at the end of it, you know, it works for your organization, kind of a thing, right? So that definitely helped, and, you know, a lot of active online forums, right? Anyway, you can just people go and talk about, like, you know, raising a question on, this is the issue in my team, you know, processes and tools, right? I really hate doing this, you know, is there something that we can do better and a lot of discussions happening on them and promote participation in the various events, to say, right, to kind of, you know, being at internal event or an external event, making sure that, you know, you're promoting your teams and your team members to kind of go and, you know, participate in those events. This is a quick example that I would want to give. This is Window to Agile. This is basically about a geographical distributor team. There was an overlap between the two teams, between the U.S. and Brazil, so how did they kind of solve the problem of, you know, a problem of not being co-located, right? So how did you kind of go about doing the stand-ups? You know, they were having some stand-ups. So this is what it is, right? So this is what it looks like, right? So we had a co-located team, but there was an overlap and we had this video conferencing on the other side, you know, where you actually can go and talk to them. It's as good as, you know, you're working with them, just kind of, you know, that the window is always open as in when you go near the window, you can see the person, you know, there and working and maybe want to talk to you, right? So this is something that the team had established at that point in time to see, you know, that this was kind of a success to an extent, but it kind of works only when you have a, you know, two geographies which has some overlapping working time, you know, but, you know, so this is one of the examples from that. So just want to conclude this. So basically, you know, the first thing is invest in foundation. That's really important. I still remember one of the, you know, statements from one of the architect. So he used to say that for a developer, you know, so building the thing right is more important than building the right thing. So, you know, so that's so true because, you know, building the right thing, I mean, I know that ideally it's the owners is on the product owner or the product manager to make sure that, you know, there's a course correction and, you know, they're building the right thing, they're genuinely responsible for making sure they're building the thing right so that, you know, there's no tech debt tomorrow, right? They're basically taking care of all the unit tests and the refactoring, everything is considered, right? So they give the best quality of the code, right? So that's what it says that basically invest in foundation. It kind of helps you to, you know, you know, be success in the transformation journey. Bind from the management that we have heard, like, you know, numerous times since the morning, so I don't want to re-emphasize on that point. Because the, you know, unless you have that, you know, you have set up for a failure, that is for certain, right? I mean, it can't go beyond, especially for when you're trying to scale it, it can't go beyond a certain point when you're trying to do a bottom-up approach, right? You definitely would need a top-down, you know, bind in terms of, you know, making sure that the transformation do work and work with structured freedom. This is something, you know, which is about, you give enough freedom to the team, but at the same time, you tell them that there is a boundary around them, right? So that, you know, they can be more innovative, but at the same time, you also tell them that, you know, you can't just go and cross your boundaries. So it's more of like, you know, working with a structured freedom, basically, right? So you kind of tell them that, you know, this is the thing that you could do within, you know, and so what it helps is, you know, it kind of brings in the innovation, you know, element into the team, wherein they can go outside the box and think about, like, you know, something else. But at the same time, they know that, you know, they have to go back and, you know, deliver on these particular pieces, right? So it is not like, you know, I'm doing completely something orthogonal, which doesn't even relate to my work, right? So that's about, like, you know, working with the structured freedom. So this was a quick 20-minute talk. I just tried to keep as short as possible in terms of the content slides and, you know, so I hope I didn't bore you much. So that's pretty much. You can connect me at prefool.row at the gmail.com. And thank you. Thank you for your time. Any questions? It is true, but at the end of the day, you have to have someone account. So the question was, in Agile, the quality is the responsibility of the entire team, but not just for the individual. I mean, I would say definitely yes. So much so that, that, I mean, the QE was almost eliminated from the team, or rather from the organization at some point in time. I mean, it's about the same organization where I kind of, you know, giving the experience report from, because the owners was completely on the developers, basically, right? So they had to literally, you know... So the option was, basically, either the QE would move into more of a development role, kind of, you know, they kind of also do some of the development, and it is not just the QE's responsibility anymore to, you know... You know, various other processes had come in about making sure the code review was done at multiple levels, and, you know, so on and so forth. So that was a separate team.