 Some of my talk really is about my experience and the experiences of my fellow colleagues, fellow BlackBills, as we implemented and kind of adopted our teams through the agile process. So, this is just more like an experience sharing and, you know, what are the things that we did, what are the things that we enabled as BlackBills and BlackBilt and agile is just like, you know, do these two just go together or, you know, they are just two different things. So, it's just kind of sharing my experience. It's just a quick kind of walkthrough of that. So, I won't spend a lot of time on this. This is just kind of for the, you know, for the uninitiated. In GE, we do what we call as lean six sigma. So, it's a blend of six sigma, which is more focused on improving quality, both on products, processes, through reducing reduction of variation, you know, trying to keep the variation to a minimal on processes. But there's a lot of heavy emphasis over late in GE on lean. And lean really is, it's about reducing waste. And you see a lot of these concepts in agile today. So, it's very complementary when you talk of lean six sigma and agile. And essentially, and that's what I was trying to contrast here, you know, it's plan to check act on one end. And if you look at six sigma processes like the make, which is define the problem, define, measure, analyze the problem, try to come up with a solution, improve it, sustain that change. And then, you know, back again, driving these small incremental improvements, you know, instead of taking big leaps of change, take those small incremental steps, and kind of drive more sustainable change and process and product improvements in the organization. So, it's a blend of both process and product. Sorry, my slide's jumping ahead. But that's kind of how I see it. It's a good blend and it's a good complementary kind of thing, both agile as well as six sigma. So, they're not really diverse or kind of different things. So, you know, this is, this is my mental model of, you know, how we went through the agile adoption and, you know, what our, or my toolkit looked like, what the toolkit of my fellow colleagues looked like as we took the team through, through this whole process. And we're still going through it. So, begin, you know, you know, this is nothing six sigma here. It's a lot of initial coaching as a process, you know, as champions of the process, you kind of get with the teams, embed with the teams, practically serving as agile, as any agile coach would them and the processes and, you know, kind of get them through the motions of it, get help, you know, seek out help in the community, get people who know, who face similar problems before and, you know, kind of help the teams go over that learning curve. So, this is, you know, it's all about coaching and being with the teams as they go through the process. And the good part of having, you know, in GE, we have these roles, which are more full-time. And the good part about these roles is you get a full-time army of consultants for free, right? And, you know, they can embed with the teams. They are process champions. They can help sustain transformation of the scale for an organization, which is, you know, I'm talking about a big organization here. So, we definitely need that kind of strong support within. And also, these guys can, you know, get in folks from outside, look broader and all of that. Next thing that we started focusing on as the team is going through the process mechanics is essentially a lot of focus and emphasis on continuous integration. And this essentially for us is one of the key ingredients to being a successful agile team and getting us to, you know, really, when we talk of continuous deployment today, these were the baby steps that we had taken way back through simple projects, use of simple tools, which with just common sense, you know, nothing, you take a simple value stream map, look at your, you know, if it's a big build process, look at that, analyze the bottlenecks. And typically we do this in groups of, so that the entire team kind of comes together. It's a simple exercise, doesn't take a lot of time. But quickly you can chalk out, you know, these are the areas you need to go change. Maybe some of these are technology changes. Some of these are, you know, just simple things that the team can do and enable. It's just purely within their control. We also use simple tools like looking, you know, when we talk of build portability, we're talking of cross site teams. In this case, we want the similar experience in different sites. So we look at simple tools, that's there in Six Sigma, how do you reduce variation for your builds, you know, what's, what are the local factors influencing those and all of that. So from those baby steps, slowly and gradually getting into more formal, you know, definition of what success means on continuous integration, getting to continuous deployment. So again, defining some of those measures along with the teams, helping the teams understand where they are on these different axes and, you know, planning some of those improvements, really the whole focus is to get the whole team into continuous deployment. So continuous integration, continuous deployment, one big area of focus along with the whole agile transformation that's going on. So, you know, that's like one piece that's going to hold this together. It's going to enable the teams sustain that change. The other thing that we experimented a lot with was, again, a lean concept, visual workplace. It's used a lot manufacturing. We do quite a bit of that in software development also, having the right indicators, you know, the right visual dashboards, right from your build statuses, even to your program and process metrics and all of that, but having that clear visible for the team because those are the radiators that kind of keep everyone on the same page and, you know, so we've been, these have been well received within the team. So we got a lot of these at the development center. Now, this is a change. So, you know, it's a team which is working in a different manner, a different fashion before and using, you know, concepts from lean, you know, it's easy to kind of help the team embrace changes like these. So that's kind of the team there. Retrospectives. So nothing new about it, but once in a while, we kind of have facilitator retrospectives. So getting in with the team, using tools, you know, we've all used agile assessments before working on what those agile assessments are specifically, you know, for this organization, helping drive some meaningful actions out of those conversations. We've also experimented with cause maps before, you know, trying to look at the multiple causes that could have happened in any significant failure. So if the team is not consistently, say it's not consistently meeting its print goals for successive sprints, or maybe there's some critical issues that are repeatedly getting discovered, what's cause maps have been a good tool to use to identify, you know, one or more process failure points can. So some of these simple tools, again, borrowed from the Lean Six Sigma toolkit, employed into and embedded with the Scrum or agile processes. So one thing which we've been trying a bit lately is Kaizen, which is really another Lean concept, small incremental changes. So these actually come out from your retrospectives. It could just come out, you know, during the day-to-day working of the team. And the idea is, take your team step by step, improve them, one level up, one level up, but small baby steps. So we got, we tried different things, get small Kaizen boards, moving around, every team has a Kaizen board, or you could even post these on your Scrum board, or you have your eKaizen's. We've tried different things with this, but the idea really is to drive us an incremental improvement culture, leveraging Kaizen, again, a Lean tool. Last but not the least, metrics. And this is, you know, one area where, you know, we've not, the last word has not been said yet. So a continuous refinement of what are the right measures for the teams, both for the teams, for the management, for the stakeholders, you know, look at different aspects, execution, health, innovation, culture. So different measures would go into a lot of these details, but essentially that's another area where we help teams focus on giving a good measure to their success and helping them understand, you know, what are the areas they need to kind of focus more on and improve. Sustaining change. So, you know, just like in any true Six Sigma project, you have what we call as the control phase. And essentially, it's not about control, but it's about sustaining change. So two elements really there. One is the continued leadership support, the top-down support in the organization that, you know, this is the process, we support the teams, the teams are empowered to do the right things. The other thing is having the right systems and structures. And, you know, by systems and structures, I mean, as an organization, as big as GE, you know, you have these huge processes. So how do we lean out these processes, make them more relevant for software development, make them more agile? How do we kind of put very simple, what we call as work instructions, you know, leverage, you know, the wiki and easily accessible sources of information for the team. Simple one-page instructions instead of 100-page manuals and processes. So a lot of work went on that end as well so that the teams can kind of understand and, you know, what it takes to do their job and all of that and help with the onboarding of new people on the team and so different things there. So this is kind of, it's a short talk really, but that is roughly if you see the different tools which are, you know, it's all common sense. I've not talked of anything which is really outside here of what the group may know already, but it's really about, these are very complementary. So Six Sigma is not alien to agile, you know, and definitely in GE we have an organization of dedicated black bills who kind of really support huge organizational transformation that we're going through and, you know, we've made good progress in that as well. So with that, you know, that's a short talk, but that's kind of what I had to share today. Yeah, the Kaizen boards, we have just simple boards which, you know, with these small cards where people can write up suggestions for improvements. Say a build machine is too slow, you know, that's an example of a small Kaizen, you know, can you just replace the build machine or can you use a different tool. So those are simple which the team can pick up during the retrospectives and, you know, take simple actions upon to improve their processes. Nothing different from retrospectives, but it's more life, it's more in line. Yeah, yeah, that's a good question. So the question is on, you know, what tools from Six Sigma help in agile and really our emphasis has not been to kind of put a lot of tools. Six Sigma is really about process change. It's about culture change. And use the simplest tools that can help you meet your goals. So a simple cause map, or even if it's a simple, you know, the visual workplace, that's another example. Use simple tools to do FMEA is used quite a bit. We've also experimented with cause maps. That's another tool. The other things I showed you with continuous value stream maps, just comparing variations of builds and those kind of things. So very simple tools, essentially, nothing much. We don't do hypothesis testing. Yeah, that's, again, the last word has not been said on that. We've experimented a bit with agile assessments. Look at what are the values we want to, we want our good, you know, the empowered agile teams to have. We looked outwards in the community, got some ideas from them, blended into our own as agile assessments. So that's one tool that we've used. We've also tried different other techniques to have some measures around culture. So it's like a, you know, I don't have like one metric for that. Yeah, yeah. Yeah, we've, at least through the initial phases of the transformation, we use the agile assessments to kind of look organizationally, you know, when you're looking at a huge organization, how do you know what are the areas as an organization do you need to focus on when you look at an agile transformation? You know, is it tools? Is it continuous integration? Or is it more of backlog? So that was a good tool that we kind of deployed and we actually ran it per team, per scrum team, and then kind of aggregated that view across an organization across different business units. Most of these, because we are a product development company, so these are more, the teams kind of stay along for a while. Long as I would say five years to 10 years, some of these products that we sustain, these are all applications that we sell and we can't rapidly change because these are all engineering applications. So long. So now the teams, do they stay for five years? That's a question mark. But at least a good year, two years where you can kind of see the transformation as it goes along. In my personal opinion and my personal experience, yes, long live teams are successful because you go over the norming, storming, forming, you get into performing, really by the time you get into tens and 15 sprints and the dynamics are well-set, especially if you have a good team. It's, you know, if I put in a few words, it's our ability to be able to respond to change. You know, if you look at the current scenarios, we need to be able to be responding dynamically. So, lean and agile gives you a lot of that framework which was missing earlier. When we used to do two-year, three-year projects, we get locked down, you know, into a plan and we're completely insensitive about the changes that is going on across. And so, that was, you know, one key driver. The other thing is improving predictability of programs. It's much better when it's shorter compared to the longer, so, quality. That's another measure. So, these are some, and given it's such a strong quality culture, these kind of come naturally. So, when you look at lean across GE, which is, you know, a lot of GE is non-software. And then when you say agile, you know, this kind of completely blends. So, even from top down in the organization, it's very easy to kind of communicate and convince, you know, this is what we need to do for software development. You know, this is exactly what we've been doing all along in GE across the broader company. So, it's kind of blends together. I don't know what you can call it, but it's a lot agile. We follow a lot of scrum, actually, with a lot of good XP technical practices. So, that's what we do. But in order to be able to communicate change better, we do good correlations between lean concepts and, you know, how it can well apply in the Six Sigma in the agile world. So, for the larger organization, I would say this is the model. And we are coming together more as a community within the big organization that we have two, three hundred thousand people as, you know, this is what agile in software means and this is how we do it in GE. And a lot of exchange is kind of getting enabled. So, I would say broadly, this is kind of what we've been doing. We kind of, so what we do is a very non intrusive way of working with the teams so that the teams really don't feel the burden of another process or a different paradigm on top of what they're already getting used to. So, we kind of touch them at retrospectives or we touch them in their daily builds, for example, or even the daily scrums. So, the aim is to really kind of weave within instead of, oh, this is a Six Sigma tool which you should go and use. So, that's how we do it. So, we don't factor them as separate stories. We blend it. No, no, the way it works is if you see a team having a problem, you may be invited or you may be getting in also depending on the situation. And then what you can suggest is, so this is your problem. Start doing the model of that problem. You can use the tools from your tool set and help them solve their problem. So, essentially that's how it blends in with their problem. So, we don't force tools. We make good use of it. Help them in problem solving. Because that's the right way to drive change and that way the acceptability of that change is much more instead of rolling by the stick. No, and the aim is really not to enforce a use of a tool or if you have this problem, you have to use this tool. No, if you can find the solution to your problem, well, that's great. That's exactly what you have to do because as coaches and as blacksmiths, that's success for us because the team is on its own and they know how to solve their problems. But if it's a really tough problem or if you're trying to figure out how do I formulate or how do I crystallize what this problem is, you can help facilitate that problem solving with the right tool set, which is not too overbearing. It's just at this level that it's needed and it's simple. Okay, thank you. Thank you.