 Welcome everyone. Thank you for joining this session. The session as the name says is quite interesting. I'm quite looking forward to it. Our speaker Mr. Sanjeev Augustine is here with us and he'll take us through the session. Over to you Sanjeev. Thank you very much Priyanka and welcome everybody. So I really appreciate you joining me here. I'm actually broadcasting from Washington DC in the United States and I want to begin with a question to all of you. So I've been doing Agile for a long time. It's actually about over 20 years. So I wanted you to tell me if you could please take a look at the chat. Tell me your level of Agile experience. If you're novice just put in a number one. If you're intermediate number two and if you're three expert. Okay, so I can see them come up over here. We got some number of threes, a couple of twos not set. Okay, fantastic. So lots of number twos, no real like super new to Agile novices. And I think that's that's a great distribution because it makes my job easier. I can target what I'm talking about to a slightly higher level in that you guys are between a higher level of maturity. Okay, next question for you. And this is a dated question. This is sort of a generational reference over here. What does the phrase license of Raj mean to you? Who's familiar with that? And if you do, if you could just pop that in the chat. Command and control, Shamir says that. Fantastic. Any other interpretations of license Raj? Authority government controls. Yes, and could be controls in general rates and controls are in that he says she has no clue. Yeah, bureaucracy monopoly. Absolutely. So these are things that used to exist in Australia. No meaning. Okay. So these are things that used to exist when in India, there was a socialist economy, right? And there wasn't a lot of free market competition. And therefore there were there was a heavy level of bureaucracy that the government used to put in place mainly to sort of stifle business, right? And that was perhaps well intentioned, but really made things go wrong. And this was the reason why there was a time in India that you could just get maybe two or three types of cars. And you had to wait five years or 10 years to get a telephone. So many things that were freely available in free market economies were just not there in that type of license Raj system. And the reason it was such a controlled bureaucracy was that if you needed anything, you just have to go to bureaucrat after bureaucrat and get permission or a license, literally stamp for license for pretty much everything. Believe it or not, there was even a license at one point for to ride a bicycle. I kid you not. So the next question for you a license Raj is, you know, if I put I will sort of put it out there is just rules gone crazy over stifling rules, your stifling bureaucracy does bring grains everything down to a halt. So here's another question. Many of you are two and three. Here's the question for you. Can the rules be good? Can rules be good in an agile ecosystem? We don't want a license Raj. We don't want a bureaucracy. We don't want to come out and control waterfall legacy type regime, if you will. And Sam, yes, the term originally the rod term Raj came from the British, but it is also sort of appropriated into the Indian way of working. So yes, so Gautam says, yes, God rail some rules to organize yes in the form of the extents. Yes, so it depends on the rules. So rules can be good. And here is a quote that is one of my favorites. I've been quoting it for a long time it comes from D hawk. He was the chairman of a visa international. And he says that complex rules and regulations give rise to simple stupid behavior. And that's the license Raj. And that's unfortunately when we have bureaucracy. And when you have an over over ponderance of rules or over stifling over too many rules, you're just going to end up with the license Raj and these stupid simple and stupid behavior. But if we can have simple generative rules, that's what we want, right, maybe very based on the on the nature of the teams doesn't increase complexity. Yes, we want to have that a simple set of rules that are generative in nature that we can adapt as we go. Right. And that's the nature of the game. Okay, so with that preamble. I am going to now jump into my presentation and show you a few slides and we'll go through some slides over here. Let's keep these keep it interactive. You want to keep the questions coming. Please keep them coming so that I can see what's going on and we can we can answer them as we go along. All right. So what really happens from when you move from a license large and we say we don't want a bureaucratic system. And we want a agile system where things are free. Things are generative and we can have a simple set of rules. And so we try to set that up. But what we intend to happen doesn't really happen that often. And so what we have to figure out is how do we handle a situation where when we move towards a non license Raj a free set of generative rules. What should happen and what really happens and how can we close the gap between that what should happen with simple generative rules, what really happens, intended or not, and then how to close that gap. So quick note about my company it's called Lightspeed where agile training consulting and management consulting company based here in the Washington DC area. And we actually help clients all of the United States and internationally so we're hiring by the way if you're interested in agile coaching agile consulting was send your resumes into jobs at late speed dot com. Little word about myself I've been doing this thing for a long time. I'm the founder and CEO of Lightspeed and lots of my interests of their travel world cultures music etc. Doing this agile stuff for a while I have a podcast is called agile caravan Sarai you can go to our website lightspeed.com and check it out and been writing for a long time is just watching narration talk about his conference, the agile India conference starting in 2005. And my first book came out in 2005 managing agile projects and my third book from PMO project management office to VMO just came out this year in September. So do check it out because some of the concepts I'm going to talk about are from there. Right. So what I want to submit to you is that traditional governance has been problematic. When we've had larger organizations when we've had bureaucratic organization then and especially when we waterfall type of governance we've run into problems. And so I'm now going to play for you a clip from a few years ago when the US government was trying to implement a website and this is for the health care system is called healthcare.gov. And some of you might have seen in the international news that this entire system that was meant to support millions of people was developed. And after three years when they tried to take almost three years when they tried to take it live after spending something like 500 million US dollars. It crashed and you saw some of these issues with scheduled simple slippages cost increases. So I'm going to play a video excuse me an audio clip and I'll keep the slide up and just I'd like you just kind of listen to this. President Obama is putting former CEO Jeff Zients in charge of the tech surge. That's the administration's emergency effort to fix the health care website. But what about the contractors who built it? What's their responsibility? And Piers Martin Costi has this profile of CGI federal the IT company that handled the biggest piece of the project. You may have never heard of CGI but in its hometown of Montreal it's a big deal. It's an IT outsourcing company that got started a number of years ago with a couple of guys in Quebec City who didn't even speak English. Carl Moore is a business professor at Montreal's McGill University and he knows the company well. They've gone from those humble roots and then started to grow and they grew a lot through acquisition. CGI is now Canada's biggest tech company and it sells IT services around the world. Moore says the company has a good reputation but there have been some problems. Just last year the province of Ontario fired CGI for failing to deliver a health care related IT project on time. Some in Washington now wonder whether CGI's American subsidiary CGI federal deserves the blame for fumbling the Obamacare project. Sanjeev Augustine doesn't buy it. I think it's grossly unfair. I think they're a victim of their circumstances. Augustine is president of Lightspeed LLC a training and software development company in Washington. He says federal rules require projects to be divvied up among too many contractors in this case 54 other companies besides CGI. The idea is to spread the wealth and avoid overcharging but he says it's no way to build software. What folks attempt to do is to use the same model the Cold War model if you will to build a cruise missile to develop a smaller software system and it just doesn't work. He says software is best designed by small teams and unlike a cruise missile the whole project does not need to be ready at the same time. It's easier to put up a web portal in stages that's what they did in Colorado. Cammie Blay is the CFO for that state's health insurance market system which went online the same time the federal one did. We knew that there would be some things that would be delayed in rolling out. There would be some enhancements some you know customer decision tools that we would actually not be able to do until after go live. And Blay says there was only about eight contractors working on Colorado's system and one company was clearly in charge. That company was another subsidiary of CGI. We trusted them to manage the other technology vendors that they were integrating and we worked in a close partnership with them. That's in contrast with the federal website where no one contractor was in charge. CGI federal would not give NPR an interview but in an email a spokesperson said CGI was not the lead contractor. In fact he says none of the companies was the lead and none was capable of testing the system end to end. That responsibility was left to the government. All right so there's an example of all the governance in the world. They really tried it try to oversee they tried to put in place a number of governance rules and it failed. And you see it fails because when we want to deliver things fast and when things are changing rapidly the old regime doesn't work. That licensed regime in this case the healthcare.gov government regime didn't work. So what we want to do is to talk about what does work. And so I'm going to put three transitions if you will from the licensed Roger traditional waterfall legacy governments governance type regime. To a light touch governance. We still need rules we still need simple generative generative rules. We still need those rules to be light touch keep those guardrails so that they can enhance rather than hinder. So these three things I want to put in front of you and they might seem sort of innocuous right short iterations will talk about that small value stream aligned teams will talk about that and strategy linked to agile execution. But what about the governance aspect of that let's talk about that. Let's start with short iterations. Please put in the chat. The length of your iterations if you're doing scrum or save for XP how long or your sprints or iterations, please put it is other two weeks. Yeah, so most folks are doing two weeks right. So we say well scrum says we have to deliver a time box sprints of two weeks. Fantastic life is good. Second question. How many of you are actually delivering working tested product or working tested solutions services at the end of every two weeks. Can you put that in the chat. So there's got to be somebody. Most of the times this yes, fantasy of a fewer numbers sometimes. At the end of three years so incremental mode no so we start to go down a slippery slope because we say we want to be able to deliver these product increments to customers rapidly. And we want to be able to do in two weeks at the end of every sprint. And sometimes it takes longer. And here's what we're shooting for right what we what should happen is that scrum and these actual methods should give us a way to put to break our larger pieces of delivery larger pieces of a product. We want them down into minimum market of product MMPs those are the red things at the bottom. And if you're developing a new product just like with scrum is usually the sweet spot for, we might do to experience and after in this example after three three sprints, we have an MMP that we deliver to to release to our end customers and end users. So over a series of sprints or features will should call us into MMPs. And when those are ready, we can release. Now, if we if this is my if these are minor enhancement, then maybe we can release after every spring right this is the way it should work. We should have small batches that move rapidly through our system they should flow through our system. Now, what should also happen, and this is a case study, is that we should be able to overlay governance on top of that system. So if I have my delivery here my sprints, I can then start to work backwards from that and say, okay, maybe I can do some discovery I can do some elaboration of the ethics and here's my program. I can take that waterfall book of work. This is an example from a customer where they had a waterfall system and we were moving them from that from that license Raj, if you will, to a more agile system and said take that waterfall book of work break those projects into smaller MMPs put the MMPs in the product program backlog prioritize them. We can do a call review the car L stands for compliance audit risk and legal compliance audit risk and legal upfront on all of the MMPs in the product in the program backlog. We can have architectural review that anybody who's familiar with extreme programming will probably be aware of that. And then we can roll into a quarterly planning with our PI planning a big room plan. So here is an example of how we can take like touch governance, move from that, you know, big license Raj governance, have the proper generative rules, get legal review, get architectural review, get audit, get risk review and compliance, and then move into an iterative cycle or incremental cycle. Here again we can have another car review as we're moving things into the sprints. So there's a high level review there there's an ongoing iterative review, and then of course there's a lot of XP stuff in terms of spikes in spread. So this is the way this is the way it should work right now what really happens is something else. So when we try to do this, we end up with really long lead times at the beginning, both before and after development. And so some of you might recognize this pattern, we call it water scrum fall or scrum of fall or agile. Put a little yes or no if you've seen some of this pattern play itself out. Now with the advent of DevOps, we've tightened this site. The downstream processes we'd be able to release on demand, we're able to get a little handle at least on the technical side. But upfront upstream, we still struggle with this. How can we get chunks on our business side, get our business partners to break down some of our product increments into chunks? And how can we flow things from end to end? Because what really happens in our organization is not the wonderful stuff that should happen. We get stuck with the remnant of that license right. We still have to go and get some approval on those requirements. We still have to get project feasibility. And then maybe we can get two weeks prints in development, but it was still facing regulations up here upstream and regulations when we have to deliver into production. And so what really happens is that we still don't have a structured way to integrate that nice stuff I showed you. All the compliance, audit risk and legal and enterprise. And those things get neglected and this is way too late. And so you could have a discovery phase and development. So there you go. Development never starts. So that's not good. So what we need to do is to bring in those stakeholders and shift that interaction with those stakeholders left, shift our entire process so that we can go end to end. And so that we can create what's known as an agile value management office. So I'm going to skip here and show you how we can pull together a cross functional, cross hierarchy team of teams that we call an agile value management office. So do me a favor and I want to do a quick tech check over here where's my chat here. Can you put in your chat whether you can see my video? Can you guys see my video? It's not playing yet, but okay, I'm going to start playing it. Are there any other potential release changes? So is this, Jill, is this representative, the reconfiguring board? Is this the consolidation? This is the consolidation except I would say that everything from 417 is actually correct. This is not correct because we need more weeks over there. I don't have more boards. Because I'd like to take two minutes to talk about that. Do we need any further updates in the current iteration? Probably no, they need to go through there. So yes, they are planning out for more than the quarter. And what you have on the wall are work streams, the rows of work streams. There are MMPs that are making their way from the, yes, it's not big room planning. I'll tell you what it is in a second. The room planning has everybody from the teams as well. And what we have over here are a bunch of sprints. So each one of the columns are sprints. This gentleman with his back to us is a executive. He's the IT executive. The gentleman who's sitting down here is a business executive. And the lady who was at the board, she's the equivalent of a release train engineer. If you're doing SAVE, she's an RTE. If you're doing discipline agile or something else, she would be a chief scrum master. And then these are some of the senior members of this agile value management office. And then you've got some team members here. Not all of them, but some representatives. So how is it different from SAVE? The process is similar to SAVE, but this organizational construct is different in that it pulls together people end to end across business and IT at the middle management level. And we have some other folks from the executives as well, executive teams, and we have team members. So let me go back into my PowerPoint and show you what is the makeup of the organizational construct, which is that we're calling an agile value management office. So here we have it. Our goal is to create that seamless network organization. Can we go across the teams? Can we get flow of value across those teams? Now, generally things are getting stuck at the management level, right? Decision-making velocity gets stuck. So what we want to have is things moving quickly from start to finish. And the bottlenecks are usually above the teams. They're not at the team level. So what we want to do is get one or two people from the team. We'll get these to be elected. We get a couple of executives, the business and IT, and then we have a cross-functional group, both business and IT. And if you look at that room, there's about 30 people or so. And they are looking at everything that's coming down the pipe and they're planning things on a regular basis. Now, is this a quarterly meeting? No, this is a weekly meeting. Sometimes they even do it twice weekly, two times a week. And what they're doing, they're looking at things across the portfolio. They're looking at things across the portfolio level. And somebody mentions that Clashman's big picture gives a similar view. I'm sure it does. We've used JIRA, Align for this, Lean Kit, different tools. And you can look at it and make it all digital, right? So we have this team of teams that can help us look across all of this, all of the enterprise from end to end, right? And does it not applicable to all kinds? Actually, it is. So here's the interesting thing. That board that you saw had at least half of the projects were waterfall projects. So we were just managing the dependencies across both agile and waterfall projects. And so the important thing was that on the agile projects, we were able to break down the increments into smaller MMPs for the waterfall projects that wasn't possible because they weren't delivering product. They were delivering documents, right? So it is a question of managing the dependencies. Okay, when are you guys going to release? You'll release three sprints into everybody else's release. So we'll make sure that we can make sure that we're pulling people in. Why not have all team members? Because twice a week, once a week, we still have big room planning for that. And there is something called cognitive load. If you look at, there's a great book and body of work out there that's called team topologies. And we just kind of have, it doesn't make sense to bring everybody for every single meeting. It's not productive, right? So what we want to have there is a representative group of people who can, who can remove the impediments and make decisions and move things along. And that reduces the cognitive load on the people on the teams. We still have representative from the teams. And so their work is represented there. And that allows us to control cognitive role and just the mechanics become easier when we have representation like this. Okay. And this is more than one project. This was 21 teams and it was a whole portfolio to Sam's question. All right. So how are we doing? We got about 20 minutes. And let me see. Any other questions did I not, I think I answered all of the other, any other questions that you want to pop in the chat? This is, this is saying, okay, we want two weeks prints or iterations. We want to overlay governance on top of that. We want to make sure that we have in that room people from compliance audit risk legal vendors. And in addition to all of our program and project and product management folks as well as some team members as well as some executives. And that allows us to manage the dependencies from end to end and make sure that we can have the right audit points, the right compliance point. And all the proper type of governance. And this is like, like touch governance because it intrinsically is an agile way of doing that. So we're bringing all of the non add historically non agile folks into an agile way of working. All right. Next question for you guys. What is a value stream? I see that folks are familiar with safe here. So what is a value stream? Anyone know what a value stream is? Yeah, business value. Right. So sequence activity there. Ron Nutt's got it, right? It's a sequence of activities from start to finish. So if we say that all agile methods or all of agile is based on lean, right? And lean says, we have to anchor what we do on the customer around the customer. So how can we go from customer through all any an idea that we have a value that we have to deliver? Exactly. Deep says it value that we're delivering to customers. Initial idea through all of us silos and back again. And that sequence of set or sequence of activities is what we call a value stream. If you're taking a UX perspective, user experience perspective, we say, well, our customer is going to go through some journey. And what we want to do then is to line up that value stream along the customer journey. And then what we say is that I can align my teams to that customer journey or to the value stream, the sequence of activities. And then what I can do is I can line up the MMPs, the minimum marketable products, line them up and my team can work on one MMP at a time. So now I have my stable teams. I can take this collection of teams and I can align them to the customer journey or the value that we're delivering to our customers. So this is what should happen. What should also happen is then if I'm applying lean portfolio management, it's another case study where we've applied a portfolio Kanban. Kanban is a big visual system or a big visual sign. And what we want to do is to control the flow of value. This is all pre-developed development. So this is all that upstream stuff we were talking about. And in this case, you have a funnel selection prioritization program backlog and then we implement it. The way it gets manifested here is that all value is linked back to an objective and key result. We have everything in this row linked to this first OKR, objective and key result. Everything in the second row linked back up to the second OKR. And then what we want to do is to make sure that we're going through business requests, wisdom ranking, if you're familiar with the SAVE, estimation, business case, approved and selected. And so yes, we do PI planning but is all the work visible at all times because PI planning is about taking the stuff that's here in the right mode and start figuring out how to implement it. And what I'm talking about is all the stuff upstream of PI planning. And again, at each one of these junctures, we can have compliance, audit, risk, legal, we can have regulatory compliance, we can have business compliance, we can have all of our governance introduced over here. So this is our portfolio con bond. This is what should happen. But what really happens is that the organizational silos still persist. It turns out that just to go from start to finish, we have to traverse about nine silos. So most organizations still look like this. So yes, we need that wonderful flowing portfolio if we will. But our organizational still looks like this. And decisions are not swift because we have a hierarchy. So we have a lead time lag, right? So we have lag in going from left to right. But we also have a lag in decision velocity or decision lag. And that's because of the hierarchy. And that's another reason why we want to have that agile value management office because in that agile VMO, we can expedite decisions and make sure that they get done quickly. Because we have horizontally, if you will, we have an issue going left to right, getting value to our customers. And then vertically we have a lag in terms of decision making velocity. And so what we need to do is to shift left and integrate end to end with business. And so here's what we want to do. Those value stream teams, right? Let's align them to a particular product. And let's talk about discovery, refinement, delivery so that all the work that's coming. So that stuff you saw up front on that portfolio con bond, that's here. Then there's some refinement and there's delivery. So this is a program con bond. And you can see this quarterly planning here, this monthly planning here, and there's delivery every two weeks. So what we've done now is that we can take all this work and we can regularly feed it into our teams. If you're doing the scaled agile framework, then we'll collect those teams and into a group and call them an art. And then we'll take agile release train and then we'll align those agile release trains to a value stream team, right? Or to a value stream, excuse me. But this is what we want to do from end to end. And this is how we go from end to end from business to it and back. So even if you have a legacy organization with those nine silos, we can now make sure that things are flowing or streaming. So here's another case study where we had strategy, organizational units, the objectives and key results laid out, all the demand coming into the VMO, the VMO doing big room planning, and the value stream owners, in this case, sales, customer service and marketing. Okay, so there you go. Best case, absolutely. This is what should happen, right? So I'm going to ask you guys, what are some simple ways that you can implement like touch governance? So I would like you to please go to, let's see. I'm going to see if I can pop that into the chat. Let's stop sharing. And where did my PowerPoint go? Please go to menti.com. And I would like you to pop into menti.com some ways that you can implement like touch governance as we've been talking about over here, right? All right, some folks already here. That's fantastic. Let me share the screen. So that you guys can see what's happening. Little relationships, follow up, value stream mapping, excellence, quicker decision making, dispersed. Yeah, awesome stuff. Follow up and let the team do it, less hierarchy, OKRs, team definition of done, or restructuring focus. Yeah, all great ideas. Thank you so much. So I appreciate that input. We need we need to make sure that in order to make the right decisions to make sure we're building the right thing and to make sure that what we're building meets business outcomes that our strategy is linked to agile execution, right? And this is what should happen. We should have a clear chain of why. Why are we working on this? Everything on that wall that we just saw should be linked back to a strategic outcome that is captured by an objective and a key result. So we'll have themes and those objectives will be there. And then we'll have initiatives and we'll have key results for each one of the initiatives under the themes. So we should have OKRs that drive all of our epics and our stories. This is what should happen. Now, what really happens is that that stuff just doesn't happen. Execution falls short of sanity. And you can see the failure that we may have the greatest strategy when execution falls short, right? And 82% of Fortune 500 CEOs feel that their organization is effective as strategic planning, but only 14% say that they're actually implementing. And 50% say in Harvard Business Review, let's say that strategies fail to deliver those results because of poor execution or poor linkage to execution. So what really happens is two things. One is the strategy itself is unclear. And the second is the strategy is disconnected from execution. So we might be doing great stuff on the ground with our agile teams. But if we don't have the right direction, if you're not building the right thing and we're not linked to moving the needle on the right business outcomes, then we're just generating a lot of waste. We're doing things that are not really valuable to the organization. And so it's really important from the get go to have that North Star and to make sure that we're defining all the work, making it visible as MMPs and then tying those minimum market of products or MMPs back to the OKRs to make sure that we can actually deliver value. So how do we do that? Here you see is an example of case study where we have our OKR. We have epics that are lined up with those OKRs, they have features, and then the collection of those features. Here's one, two features that are bundled into this MMP. Here's another MMP here. And both of these MMPs clearly link back to this epic, which clearly link back to an OKR. And of course you can do all of this stuff in your tool, right? Whether it's Jira Lyons, your big picture, or Leankit. This is what we should be able to do. Now, what really happens is that we are unable to do this. So we need to make sure that we can define this clear chain of why. And here's how we go from top to bottom. Capture the strategy with OKRs in some sort of strategy capture session. Make sure we can do value stream mapping, align the teams by value, link the value streams back to each OKR. And then in our BRP, our big room planning, or before, make sure that we can align and link all of the work in process, all of those MMPs back to each OKRs. So to go from a strategy to value stream, and then all of the agile work in terms of epics, features, and stories, all linked in a chain. And at any point in the chain, whether it's an epic or a feature or a story within the product backlog, or higher up the chain, whether it's an initiative or a theme in the portfolio backlog, we should be able to work on it and say, why are we working on this? Well, it's because of this OKR and this key result. So that clear chain of why is very important. So here's what we were talking about, just to pull it all together. Three transitions to light touch governance, those short iterations with integrated oversight and governance. The value stream team with the value management office of VMO overseeing it and making sure that everything is being delivered end to end. And then the third one is strategy linked to the agile education. Right. So I'm actually going to stop sharing now because we've got about five minutes and I want to use that time productively for questions. So at what time, Sunday, I want to know at what time a tech team should be involved right from the beginning. The tech team members, you're going to have a couple of those members in that agile VMO and they're going to be involved with from the very beginning. Right on that left hand side where I talked about program planning. So tech teams members are going to be involved from the very beginning. Maybe a tech lead, maybe a tech, you know, could be a developer, maybe a business analyst, but they might be going once a week to that agile VMO meeting. All right. Operations, yes, everybody should be involved. Right. Operations end to end. We need operations. We need deployment. We need production folks on that's downstream upstream. We need a business partners. And when I say business is not just product managers, but it's sales is operations is marketing HR, right. Legal. Everybody should be involved into it. Since you have a longish question on Q&A. Oh, I haven't looked at the Q&A. Sorry, let's take a look at the Q&A. Organizations started starting with spike and review for new features to get approvals. That which is very, very interesting. Right. The idea of a spike is that it's an experiment and it's you shouldn't have to get approval. It's like, I need three days to go to go off and and to experiment with this. So the reason you do a spike is so that you don't have to get an approval. So I'm sorry that your organization is is doing that, but they're doing it wrong. I just show them go to go to extreme programming.org e-x-d-r-e-m-e programming.org. And you're going to find the explanation of a spike could be technical spike could be business spike. And there's nothing about getting approval there. In fact, the idea of the spike is to help you get through any sort of jam pack. What's the difference between MVP and MMP and MVP is another experiment is a product experiment. We just want we want to try something. It's not ready for production because we're just going to try it. It's an experiment and MMP is a piece of an actual product that is going into into production. Right. How does the business move from ROI to OKR? It's not not an easy task. I hope you don't. You could still measure ROI, but OKR is objectives and key results are pretty straightforward. There's, you know, there's a lot of work out there with in terms of OKRs. You could still measure ROI, so you don't necessarily have to move from ROI to OKRs. You can implement OKRs in addition to that. We got about two minutes. Do you see any conflicts with multiple groups while defining the strategy? Yes, which is why they don't define the strategies. If you remember, I said they capture the strategy. The strategy is defined by the executives in that triangle I showed you. There's the teams, then there's the agile VMO and above that there's an executive action team. And the action, the executive action team, the executives, they define the strategy. And then they say, this is this is how the strategy. This and then the agile VMO has helped some capture the strategy with OKRs. Parts of the organization which don't embrace an end to end or bottleneck. This needs to be fixed by COS or at least somebody at that chain. How can you reduce the work effort across the work? Value stream, get people talking, set up those end to end teams, implement all three of these steps. This is all about reducing work efforts, reducing decision making time, and reducing the lead time so that we can go quickly from end to end. Thank you so much, Sanjeev. It has been an amazing session and I have learned quite a lot from the chat, from the other conversations. It seems a lot of people have taken away a lot of insights from what you said. Thank you so much.