 Good afternoon everyone and thank you for making time for this session. As you can see, Agility in Complex Transformation Programs and Oxymoron is the title of my session. A little bit about myself. My name is Yashasri Barve. I am working as an Enterprise Agile Coach and a Transformation Consultant at TCS. I've been with Tatas all through my career. It's gone complete 25 years in July in the IT industry. I'm an author of this book, the image that you see here, Agile Mindset, which is available on Amazon. I'm a blogger. I blog at my personal website. I'm an avid reader. I'm a speaker at conferences. I'm also a volunteer for TCS's Purposeful Life. We have an initiative which is called Youth Employment Program. So it's a lot of pleasure to talk to people who are like the youth who are from underprivileged background to prepare them to come into corporate. So that's about me and my Agile journey actually started in around 2007 and I had been working as a technical architect then. I just got fascinated by the way we had been... Do you need some time? So I just got fascinated by the way we were collaborating with teams, working with business to churn out something which was working software. Rather than having a project manager, I didn't even know when I switched my role from a technical architect to an Agile coach. And it's been a great journey since then, working with various product teams, helping them as a scrum master as an Agile coach to evolve their way of working, helping them in transforming and also delivering working software. So when I started, mostly I had been working on products like one or more teams. That's how it started and the way things were looked something like this. So this is like the road construction in a local neighborhood. So there are limited number of stakeholders, limited number of people who are going to get impacted, maybe thousands. If this is somewhere in Mumbai, even a local neighborhood road would be like thousands of people will be affected. But it will normally be a single authority, single administration who will be involved in construction of a road in a local lane kind of a thing. In the recent years, the work that I have been doing, which is on large programs actually started something like this. It started looking something like this, which is like a mega highway that gets constructed and that is connecting multiple states. The complexity levels are very different, right? Normally to construct a mega highway across multiple states, it would mean that we have to have many, many multiple things getting involved. Multiple state authorities, state governments, different political parties. There will be legalities involved because land acquisition has to come in place. Forest department, N number of resistances that will come from the locals. If it is the Mumbai Nakul Samruddi highway, which is there, we would also have to take care of animals. Like there is an underpass that had to be created so that elephants could cross. So the kind of complexities that happen in such a program is enormous as against, you know, simple road construction that happens in a small city or a small town, right? Well, of course, I am not involved in this domain. I am still talking from a software domain, but yes, the complexities of having those multi things are still very, very valid in that case. So coming back to software domain, I thought, let us just set some context with respect to what do we mean by a transformation program? So this definition is coming from PMI. It is coming from a paper that was presented at a PMI conference. And it talks about how the transformation change the way people, processes, technology, physical infrastructure, etc. Change to cover the new capabilities that have to be developed for organizations to achieve whatever are their new outcomes, right? Like for example, the mega highway that we spoke about, it actually helps people to commute in much, much lesser time than they would have already taken to commute across multiple states. Or it might just explore the opportunities for trade. We might have many more opportunities, many more potential opportunities for people to travel and look for new jobs and things like that. So lot of new opportunities open up whenever we undertake such transformation programs. They also are driven by a sense of urgency that we want to complete it in one year, two year, whatever, you know, multi years that we are looking at. And they are very, very broad in terms of their scope as well as in terms of their impact. So typically any of such transformation programs will be. When we talk about transformation programs, I know that many of you would have noticed that the number of transformation programs have really picked up during COVID and post COVID. Though of course we had a lot of digitization and digital transformation programs that were already happening. But a transformation program could be anything. It could be an enterprise transformation. Let's say there are mergers and acquisitions. So, you know, there are some enterprise level transformations that have to happen. Or those could be technology transformations like classification or moving to cloud, you know, those kind of transformation programs can happen. It could be change in the structure of the organization. So the organization wants to transform to new way of working or new operating structures and so on. So there could be many such things. And however, one thing that is common across all of these transformation programs is the complexity, right? The scope, you know, the way so many things are touched and so many lives of people are touched. That is what is probably common across these. Let's also look at what do we mean by agility? This one I have picked up from Merriam Webster dictionary. So the agility is basically the quality or the state of being agile, right? Or nimbleness. How quickly are we able to do something? Whereas agile will mean ready ability, marked by ready ability. Ready ability, something where we are ready. We are able, we are ready to move with quick and easy grace. So it is not that we are able to move quickly, but we are kind of, you know, leaving a lot of chaos behind, right? Like not like monkeys, right? Whenever they are agile, but the way they create nuisance, that's not what we are talking about. We are talking about something which is quick, easy graceful leader, right? So that's what we are talking about being agile. So when we put these two things in the context, like agility, which is being able to really move quickly, being able to respond to changes quickly, and the large transformation, complex transformation programs, it really doesn't really go very well together, right? And that's where I started thinking about, you know, whether it is really like an oxymoron, right? Are we really able to, none of the transformation programs say that we are not agile, right? Nowadays it's like a crime and people don't look at you with the same perception if you say we are not agile, right? Everybody wants to say that they are agile and everybody wants to label their transformations, whatever digital, you know, business transformation, technology transformation as being agile, you know? Like, for example, I am working on a SAP transformation project and yes, we are using agile ways of working, but where is the agility? And that's where I started thinking about how is agility in the context of large transformation programs. So just a quick show of hands, like how many of you are part of transformation programs? Everybody, excellent. Great. Okay, all right. So just moving to this, there was something that really triggered my thought and, you know, this was, this video is, you know, this person, anybody, do you know this person? This is Andy Hunt, one of the co-authors of the Agile Manifesto and the author of the series of pragmatic books, pragmatic proof of hammer and so on. We had an amazing talk by Andy last year and it was about the legacy, like, legacy in you. And one thing that really struck me, you know, what he spoke about last year was about how do you, like he was talking about how people are talking about, you know, how do you do stories? How do you churn out working software, etc.? Do you do the scrum events? Well, etc., etc. So he was like, he literally said that, you know, all that crap may not be agile, but there is something that very, very simple test to see whether we are being agile or not, right? So I just wanted to play that quick video. I hope I'll get the sound. So here's the test, you know, am I agile enough? Suppose there's a big change in how you understand the user requirements. There's a big shift in technology, a big shift in the market. Can you quickly and easily adapt to that change or not? Can you cause that change on purpose and then adapt to it so you have a competitive advantage? That's what agile is all about. Yeah. Did you agree? Was it what he said? Yeah. So we are talking about, like, Andy, what Andy speaks about is that if there is a change that happens in the technology or in the requirements, how easily are we able to adapt to it? Also, if let's say that change has not happened, are we able to make that change, bring that change and see how easily we are able to adapt to it? If we are, then yes, then we are agile. Otherwise, you know, we may be doing all sorts of scrum events. We may be doing all ceremonies. We may have the right roles, but we may still not be, we still may not be agile. So, sorry about that. So, going from there, like, keeping the context of the transformation programs, agile and what we heard from Andy, if we look at the industry data on the way the large programs have happened, the data is pretty bad. The data says, like, if you look at any of the analysts like Mackenzie's or the VWC's and gardeners of the world, what we see is maximum of the programs that we had, like, a lot of large programs that we had, 25 to 40% of them exceeded their budgets. They had schedule overruns, right? And, well, I have been seeing that also, like, when we are working with our customers, a lot of large programs are facing these kind of problems, right? And even more than 50% of the schedules, you know, are being overrun. And a tiny, tiny portion of 2.5% completing 100% of their projects on time, or if you see 60% of the data projects failed was a prediction, but they really found, like, 80, 85% of the big data projects, transformation projects failing, right? So, this is a really, really bad data which says that majority of the transformation programs are failing and they are not able to actually adapt to whatever changes are being brought in by the market or technology changes or whatever are the changes, right? So, this is definitely something that makes one feel that are we really being agile in any of these programs. So, as so many of you have also been working in large transformation programs as you raised your hands, can I request all of you to please give your inputs on this mentee survey quickly? So, the question is which barriers have you seen to agility in large complex transformation programs, right? You can go to mentee.com and the code is 5640-0382. So, I've put in some, it's not readable, I'm sorry about that from here. But I've put in some of the barriers that I have seen in large complex transformation programs and I'd love to see what are the things that you have seen? Any programs? Multivander scenarios? Centralized decision making? Big long releases? Big bang releases? Too many dependencies? Conflicts? Decision making seems to be along with dependencies? No time? Thank you, thank you for that. It resembles very well with what I have in my presentation. I'm happy that you are also looking at the same barriers that I have been looking at. So, I want to take a opportunity to talk about three things that really, really have impeded agility in the programs that I have worked with. First is the dependencies. For any large programs, and we heard this in the morning, right, about dependencies that dependencies are going to be there and we have to minimize dependencies as much as we can, but they are unavoidable. We heard it from Fred. I'm so happy to see that dependency there. The second is about scope and it is just never-ending scope. Never-ending changes in the requirements. It just doesn't stop and it just blows all the release planning that we have done. That is the second thing. The third thing is about team dynamics. I saw a lot of you feel that Multivander creates a challenge and actually there are just too many people, too many departments, too many teams involved and that actually impedes the agility a lot. What I'm going to do now is I'm going to talk about the problems that are faced in these three areas and some of the things that have worked. I don't think there is a clear-cut answer as to these are the 1, 2, 3 things that we need to do and then we will be able to get rid of the dependencies or things like that. If there was some, then we wouldn't see the data that we saw, but I just wanted to share what has worked and I will also share what has not worked for any of these. Any reactions, any comments so far? Yes. No, we are not talking about agile transformation programs. We're talking about business transformation and technology transformation. Enterprise any transformation program, not necessarily agile. It could also be related to agile. If you know, like for example, you started with something, you planned for maybe a couple of departments and you said that maybe this is our journey and this is where we want to be and then in one of the reviews, you keep getting, oh, but what about DevOps? When are you going to start with the DevOps side of it? It could even be related to that, but my focus majorly is on business transformation, technology transformation programs. Agility in those programs, basically. Yes, absolutely. I completely agree and to give you some examples, like any transformation that would happen in an enterprise. So just to take an example of the one that I have been involved in, an SAP transformation, there are business systems in the enterprise which nobody wants to touch. Nobody wants to make any changes to that. However, we still want, like they still use the data. So the data is still the same, like enterprise the whole database is the same. So data structure, the way data is stored is going to change once we move to some products, right, which are probably not customized, then what does it mean? Unreal impates. And we talk about also giving some examples, like we talk about, we tried a lot of things to bring in agility in the way, even the SAP things work, right? So we would say, yeah, at least in these three weeks, four weeks, we will do this, or five weeks, we will at least complete this. Legal systems, they don't even want to promise, right? Because they really don't know how much time it may take. Yes, I agree with that. Yeah, yeah, right. So even the team structure, like the way, you may want to structure the teams in certain way, but you simply can't because of the one thing. Yes, absolutely, yeah, that. Yes, absolutely, yeah, I completely agree. And a lot of team dynamics also happen because of the dependencies, right? Like for example, this legacy thing that we were just talking about. So this transformation, whichever team is actually doing the, let's say taking things to cloud is dependent on the legacy system because they are not able to do it. So there is a lot of dynamics that happens, right? Like people start blame games and that further impedes the whole progress that we want to make. Yeah, so I agree, yeah. Okay, all right. Anything else? Okay, so let's start. So I really wanted to, like whenever I thought about, you know, how to represent dependencies, I could think of a metaphor of a dungeon, right? So once we are lost in a dark dungeon, you really can't figure out where to go and you just keep finding your way out and you find that more and more deep dungeons and, you know, our way is completely lost. Dependencies sometimes feel like that, right? So you try to resolve one and then you discover there are more and you try to complete one and then newer ones come up and we simply start, you know, feeling like we are lost completely. So here are some of the things that I heard and these are things that real people said on the transformations, right? So we can't really do anything before they complete it. So there is a story, but however they are not able to do anything before somebody else completes something. Or we cannot even start working on it till the interface is not finally. So I had this one point where there was a interfacing system that was supposed to do some changes. They said that we cannot even start till you don't even complete the interface. You know, we can only start. So in spite of having a five-week sprint, the first two weeks a particular story could not start because they said we cannot start till the interface is finally at all. Or design gets stuck or the number of dependencies sometimes is so huge that there are 300 plus downstream applications that take this data, right? Whenever there is any core system getting transformed in an enterprise, there are so many systems that are dependent on, you know, with respect to data and so on. So a lot of these things keep happening. I just wanted to take a quick case study of a program that I was involved in. So 200 plus people, 300 plus upstream and downstream systems that are impacted because of the changes that we are doing. It was taking something from on-prem to cloud. And the problem is that it was not simply just moving something to the cloud, like the on-prem application to the cloud. But the enterprise also thought about taking an advantage and doing also a business process transformation because of that. So because of that business process thing, 10 plus departments, which is like one department is IT and nine departments are non-IT departments that are getting involved in the decision making, right? So with this case study in mind, I would like to share what worked for us. So the first and the most important thing which we feel helped, though did not completely resolve the dependencies is the way we managed our rate items, right? So rate is, I'm sure you would have heard, but risks, assumptions, issues, or impediments and dependencies. So it is extremely critical for any transformation program or any last program for that matter to make sure that we are managing the risks, assumptions, issues, and dependencies very, very well. And when we say we are managing, it means that it will start with identification. That is the first step, of course. What are the risks? Identifying what are the risks? Then trying to log it into your, whatever is your tracking tool that you're using as you develop, etc, etc, Excel, whatever it is, log it and then continuously track it. So it is extremely important to have it made transparent, right? So we normally use RAID dashboards for all the various teams that we have and every team is using the RAID dashboard on a daily basis. So we kind of try to make it transparent and also inspect and adapt. The kind of frequency that we have been using is for every team we do it daily. So every day, we look at what are the dependencies that we have and how are we placed, how are we going to make progress on those dependencies. And at a multiple teams level, it is twice a week. So every team does it daily and all the teams come together and look at dependencies on each other twice a week kind of a fashion. Dependency maps, again, another thing that we found it useful. So we use JIRA. So the dependency maps created in JIRA really helped us to actually look at, you know, where things are stuck and so on. And raising early blacks. So we kind of used the concept of blockers. So started flagging things as blockers is, if the dependency is soon going to turn into risks, then we started flagging those as blockers and that has really helped us. Anything on risk or RAID management, dependency management anybody wanted to share? Anything else that has worked for you? Yes. Yeah. So to understand your question better, so there is a strategic risk and then that has caused some risks at the team level. So how do we track it? So normally we have been tracking team level risks on a daily basis in the daily, connects that we have daily hurdles and strategy risks are revisited twice a week in the cross team hurdle. And of course there are separate meetings that happen for the leadership teams and they handle, you know, the strategy risks. They also discuss the dependencies and strategic risks there. Yes. Yeah. Is it a separate meetings or it is same meeting you are discussing with the RAID or risk register or something like that? So yeah, so we don't use risk register but of course, I mean any of the ways we can use it, but we use JIRA dashboards basically for RAID. So in that same daily hurdle that we have to track our synchronize our daily progress within a team, we also discuss the rates. Yes. Thank you. Okay. The second most important thing that also has a lot of dependencies and what we've what we observed is the decision making delays. Yes. No, that's fine. So the way I typically tell the team is, RAID stands for us, we don't want to discuss assumptions. So issues and dependencies are something that we'll have to manage. But I try to at least minimize assumptions. Mm-hmm. At least one is knocked off. The faster we move the assumption to either a dependency or a risk. Absolutely. A dependency naturally will return. See, it's a cyclic process. Like you can't just eliminate something out of it. Yeah. So if you're making an assumption, which typically means to say, I will assume that this technology would be finalized. I don't want to do that. I put that as a dependency on the technology stack team who's deciding it or the CTO office who's making that thing and get to an end date to say, it's a dependency on you. I'll track it as a dependency. I'm not making. I'm not making it very clear that I'm not assuming anything. I'll ask. Yeah. So that way the assumption typically is more or less in a very small number and I try to move it into a dependency quickly or to a risk so that if you make, we all know, assume word is... Yeah, yeah. You don't want to create a problem there. Yes. That's one way to manage it. Yeah. Thank you. Thank you for sharing. Yes. I think just extending his point, even in my experience, we have stopped using A there and what I've been using is CRED. Again, not referring to the CRED app or something, but C stands for Constraint. So Constraints are important to call out by the teams or even at a portfolio level to really call out that what is the constraint for me to deliver up front so that we can work on it. So A is no longer sort of use because assumptions, we'll have to deal with it. Constraints are really critical in that way. Yeah, absolutely. Great inputs, I think. Perfect. And we also have kind of laid out a model in which we have educated teams to ensure that if there are risks that are really like aging risks that are not getting resolved at all, converting it into issues. Similarly, dependencies can become risks and risks can become issues. Even that kind of education, that kind of a model is set, I would say. And that helps because at least whether we are able to solve it or not even after raising it as a blocker with the leadership is a separate thing, but at least the teams have done everything that they can. That's the commitment that we normally have from our teams. Okay. All right. So another place where there has been a lot of dependency and a lot of delays that have got introduced is in the process of decision making. As we saw in the example and typically the case, there are so many different departments that are involved. And a lot of times we have seen that there are too many people who are involved in making decisions and the decisions just don't happen. The decisions are pending there and the due dates change and that really, really impedes the delivery that we have to make. So we actually had very nice retrospective discussions on that and we figured out that major reason behind this is the FOMO syndrome, right? The fear of missing out. What happens if I'm not a part of that discussion, right? What if some decision is happening without my knowledge and so on? It's not easy to tackle FOMO because everybody wants to feel important and it has become more and more critical in today's days when there are so many layoffs and people want to ensure that they are considered important in their organizations. But we kind of try to come up with a working model with the teams and the decision makers so that we can really have small number of people who will take the decisions. It is easier for that meeting to be scheduled and decisions to be taken and everybody else will be kept informed. So this is tough thing but we have tried as much as and however still I feel that the whole decision making and the dependencies on decisions has been a major factor in delaying whatever plan we had in mind in my programs. So I also want to share like this is... So many of you would have known would have heard of Kendra Bin, Kendra Bin the Essential Scrum Author. There was one talk that I attended by Kendra Bin in one of the I think Agile Virtual Summit sometime back and it was very, very eye-opening and I will highly recommend you to look at you know if you are struggling with dependencies in your programs highly recommend you to look at what he talks about it. He also conducts separate workshops for teams to actually look at dependencies and understand how you know there could be structural or instantiated dependencies and how to... What are the various improvement strategies can you know one can get even if you don't want to attend a workshop you can go to Inolution or you can just search dependencies are killing your agility Kendra Bin and you will you know find the whole... He has so many different improvement strategies suggested I'm sure you know you will find some of the other solutions for your problems there. All right. So just to sum up what we spoke about dependencies the rate governance the risk assumptions impediments dependencies governance modeling them, mapping creating maps and tracking them focusing on decisions closing decisions on time and team structures team structures we didn't discuss but it is there in Kendra Bin's things One of the ways to get rid of the dependencies is to form team in such a way that it is a multidisciplinary team like what we heard in the morning team that can actually cross-functional in the sense where even people who are taking the decisions are also involved somebody from the data is there somebody from technology is there All right. Moving to the next one which is about scope scope often is a challenge in actually looking at the progress right and I have seen this so many places I mean I wrote it as silent support age so well there is and it is unintentional in my context I think we heard about support aging in Fredstock but in the context that I am putting this this is not intentional it is not that somebody wants to delay the whole program so they are putting in new things but a lot of times I have seen that you know there are too many missing pieces too many new things that keep discovering that it is very very difficult to really put together the whole puzzle of what exactly is needed in this transformation program So I have heard things like now this is SAP we always do big bank releases it is not possible the first one is my husband who says this right he is an SAP consultant and he we never talk about agile at home because you know he does not believe in it he talks about SAP and big bank releases right so either it is first-gen or first-july first-july date missed we will go next first-gen and so on so it is very very ingrained in the way he works and you know many of the people who are working on large products and so on or people just do not know what is expected in a story or in a requirement that we do not know we cannot even commit how much time it will take it is very difficult and that happens in transformation programs right if it is a small product that we are working on and we are discovering and constantly working with product knows it may not happen but when we are talking about multiple stakeholders being involved multiple stakeholders giving inputs it is very well possible that it happens so I have one more mentee for you just a question which techniques have helped to prevent scope being sabotage so I have to go to the next slide product ownership MVP MVP reprioritizing managing expectations governance thank you so I have an example of a program which is around 300 plus people involved in the program 50 plus teams which have multiple stakeholders giving them requirements and there was a 50% schedule over it was a one year program which already got delayed by 6 months so which is like a 50% overrun and one of the reasons like some of the reasons that we figured out is the lack of strong product ownership there are multiple stakeholders and there will be multiple stakeholders because it is a large program right we will not have only a couple of people but so many people but if the team is getting confused and the product owners themselves don't know how to prioritize and what are the right things that the team should take up next and when they should be completed then there is a big problem and big risk to the program so a very very strong ownership is needed and managing stakeholders right the product owner will understand that it is impossible to satisfy or make everybody happy they have to choose what is it that really makes sense for the program to move ahead and accordingly take a call and it is also critical to do the vertical slicing now it is very easy to do vertical slicing for products right because we can simply go by feature by feature it becomes more and more complex when we have programs wherein maybe a small size doesn't make sense right we had a lot of challenge in convincing people who are working on SAP projects and they are developing RICEFW objects as they call it which is reports, interfaces, convergence forms and workflows that they can do a slicing in a way where they can come up with some kind of MVPs right and once we could demonstrate one of that can happen then they themselves could come up with multiple MVPs and we could actually take smaller piece which could be done in a sprint and then you know evolve over it it is like a very no brainer kind of a thing for any scrum teams and product owners when we are working on products but not so much when we are working on large programs but I just want to say that it can be done and we have tried it with a good percentage of success and the most important thing is prioritizing and reprioritizing descoping so we like the previous program that we just spoke about took a stand and said that you know you have to know what is it that you really really need for day 1 what is it that cannot go without what are the things that cannot wait after day 1 plus and doing this rootless kind of prioritization is extremely critical otherwise we will get into the same problem that we had in waterfall world wherein we want to do everything so the scope has to be finished so the schedule will go on right like the 6 months program will go to 1 year and 2 years and it will never get over it is not easy but it is extremely critical to do so asking the right questions you know my product owners has to be really a strong product owner for that maybe we can take questions if at all there are any thoughts you want to share later I just want to finish up some of the things that I had so this was about the scope issues wherein having strong product ownership, vertical slicing focusing on MVPs and also maintaining traceability also we did not speak about traceability I think but traceability is about where we have started like we have started to complete something and of course that has maybe you know you have large requirements and like in SAP parlance we have BPML business process master list and breaking it down into L1 L2 L3 L4 and whatever we are working on how is it related to the business process right we have a story or we have a small piece of requirement how is it helping us to have a particular piece of requirement being fulfilled is extremely difficult to to know the last one which is about team dynamics right so the barriers of us versus we versus ours versus you know they themselves right very very very very evident we also saw most of you agreed about the multivander environment right we here at D in and out they only want to increase their head count which is in case of you know if there are vendors that have been hired to work on certain things and if they say that this takes this is going to take more time or we need more people this is what we are they only want to increase their head count that is why they are doing this they do not understand system or what were they doing all this while and how can they come up with some critical requirements right they were sleeping all this time what all of these things which are putting blame on the right they here could be a different department a different vendor different role a different team different region right in this region it's always like that or they never know what they really want that kind of a couple of things that have helped this is a very very difficult problem to solve but a couple of things that have helped is alignment to the vision so over and over talking about what is it that we as a team like the whole program team want to accomplish and forget about this is what this vendor wants to do or that department wants to do and so on having that vision iterated again and again and getting an alignment to the vision really helped and leadership so we I have had fortune I mean fortunate enough to have leaders who speak about I do not want to hear that this vendor could not complete this or this vendor brought in these challenges I do not want to hear that I only want to hear how you can now work so that we are able to fulfill our vision it's extremely critical the leadership gets into you know doing five eyes on why this vendor could not do certain things the program is doomed because then everybody simply gets defensive and no real causes will come out and people will simply try to you know just do something for the sake of doing it and for the sake of avoiding penalty and so on right the other thing which I think is very very critical and we did this for all the teams is setting up the working model who will do what what are the various roles whose responsibility is what making it laying it down making it extremely clear crystal clear by having a discussion within the teams right so what is what is it that our working model is what are the team norms that we want to set and the last important thing is change management and I'm not talking about the change management for the end users of course that is important because I mean there has been an instance when a CFO told us that don't worry about the adoption we will take care of it it could not take care of it the whole rollout got postponed by six to eight months I think because you know the people were simply not ready to adopt the new system but I'm not talking about it I'm talking still about the IT team because different people are working with each other they may be familiar with certain ways of working but now we are talking about probably different ways of working when they are working together they may be just to give you an example we have a custom application development team which is highly mature in terms of DevOps and they have a dependent like they are upstream system for an SAP system and the first time when we meet they say you do not have CICT I mean this is not how we work yes right but this is SAP we are still you know going to work on it and we are trying to figure it out so it is different ways in which people are working right like the SAP team works in a different way the custom application development team works in a different way so that management is a real challenge that we have to work with ok alright so yeah so just one last minute so just to summarize about the team dynamics getting everybody aligned to the vision having leadership support for doing that extremely critical things before we can even think about having the team dynamics making it better defining a working model collaboratively not like one person defining model and just dictating it to others but team coming together and defining how they want to work together very very important and change management we really have to bring in that empathy towards we have to bring in empathy towards others and you know educate others to bring in the empathy towards us and that is probably you know the way we can help in terms of improving the team dynamics in a program ok so that brings me to the end we talked about dependencies scope we talked a little bit about team dynamics and a few things that have worked for us in certain ways like rate governance dependency maps decision making team structures strong product ownership vertical slicing MVP prioritizing traceability aligning to the vision change management leadership support and defining the working model so that's what I had and thank you very much and we can stay connected please connect with me on LinkedIn and this is my website name so thank you very much I just wanted to mention that some of the images that I have used are from Pixabay and some of them are AI generated images if you want you can try this deepai.org just for fun my son taught me this but it's fun to have those AI generated images thank you very much if at all any questions if any questions please or any thoughts I have a question how do you measure what does good look like in product ownership how do you point out that this is not good product ownership that's a good question ask the team probably I would like as an agile coach I will probably ask the team what is it that they believe in terms of there is the product owner helping them or how is the product owner helping them do they understand the requirements clearly are they able to work on the requirements is the feedback also going back right so I mean to have more scientific answer there are like a few questions maybe I can share with you separately that we normally ask in terms of the requirements management do we think the decisions are getting delayed because the product owner is not able to work with multiple stakeholders and you know it is not not able to prioritize things or is the product owner coming back and saying everything is high priority and you have to get these things done at all every time those are the kind of things I would look for but I think that is where anybody else wants to share anything maybe yeah okay we will take the last question yeah sure in this large transformation kind of project context do you think the contracting type for against with the different vendors would that play a major role in the process yes yes I am sure it will play a large role because a lot of times what we have also seen is like we want to have we want to have the team to come together and you know work together like I will give you an example in some of the programs that I have worked with different vendor works on development and different vendor works on testing and that is because of the compliance requirements like there are places where we have same vendor doing development and testing in some of the regulatory compliance things they need to have a independent verification something like I do not understand it completely now here there is so much so much tug of war between the development team and the testing team and the testing team is not the unit test unit test of course are being done by the developers but the final integration or the system testing that happens the final verification and validation so it will be very critical people say that I have had an instance where the product vendor said that the contract that we have is only for consulting we will not touch the code we will not do any development we literally had to get into a discussion with the leadership and you know that product vendors leadership to say that you know these are the people who can probably spend some time and do things you know do the configuration rather than only saying that what you are doing is not good and we had to literally revisit the contracting terms I mean had to revisit the terms but I personally feel like and this will come up when we define the working model let us say the whole team is coming together the testers developers or you know whoever are the advisors they are coming together they would say that my contract does not allow me to do this then what do we do if it is really critical and if it is becoming a risk to the success of the program we probably have to go back and revisit the contract and take leadership and leadership support will be extremely critical in this because depending upon the budget that they have and the way the contracts have happened Thank you Thank you very much Thank you for attending