 I hope you can all hear me, right? So this is, as you know, it is a case study, an example of how we have become business agile in a stage-gated product development environment. My name is Vineeth, and I work in Philips HealthTech as part of a big program, which we developed platform for the different businesses in HealthTech. So I'm part of that program, where we did some experiments related to how do we become business agile in a stage-gated environment. So that's basically a few experiments that we did, and the outcomes I wanted to share with you. And I'll take about 10 minutes to go through this slide, and then we can have another five minutes for any questions that come up. So before we get into the topic of agile and business agile, I wanted to know getting teams becoming agile is actually the beginning. Then when you become agile at the program level, when things start to flow, that means you're progressing. But you really become successful when your business becomes agile. So when you are in a regulated industry, all of you know that we have to go through a faith approach to product development. It's important that we do that because of the constraints of the regulations and the compliances that we have. And the QMS is that we need to adhere to. So it's important that we adhere to that. But then the question is, how do we become business agile, or enterprise-level agility? How do you get that when you still have to go through a faith or a stage-gated approach? So that's the topic that I thought I would discuss the experiments that we did and the outcomes that we have achieved. So I attempt to provide some of the outcomes that we have seen. So I will just give an outline of what did I mean by business agility. Teams becoming agile is the beginning. And then program itself becoming agile is progress. But only when the business becomes agile, you reap the benefits of what you do. So I would just like to start with the definition of what I meant by business agility. Then I'll get into a small introduction of stage gates for those of you who are not familiar with stage gates and the approach of stage gates. Then stage gates is a very significant model. It's a very good process model. It has its very good advantages, but it also has some bad and ugly sides if you stick to it too much and we lose the business agility. A little bit into what are the pros and cons of stage gating approach. And then some of the experiments that we carried out in order to balance this stage gated versus achieving business agility. How do we balance this and some of the insights that we got? I thought I would share it with you. All right, so being business agile. So what do we mean by being business agile? So that's one definition I thought I should be on the same page with respect to that. You know that portfolio is a mix of projects. And the goal of portfolio management is to select the right mix of projects so you get the maximum return on the investment that you make. So that's all about portfolio management. So when you do that, typically portfolio management is an annual planning cycle. The annual price, it happens annually. But one of the unintended outcomes of that kind of planning cycle is that the distance between the development, the work that the development does and what the business needs is too far wide apart. By the time you get what you asked for, you have things have changed and you need some new set of things. So this is one of the unintended outcomes. So what actually you need is there should be a fast and flexible flow of work so that you get the feedback back into portfolios so that you select the right mix of programs or projects to maximize your ROI. So then, either it's discovery of value or delivery of value irrespective of what the intention is. You want to discover what to build or delivering it to a market. For both, you need constant feedback from a portfolio perspective. So that is one key ingredient when I say to be business at that. A second key ingredient is the whole value stream of product development should be involved in that agility. It could be customer service, it could be marketing, it would be services to be regulatory. All of these disciplines have to be involved. The whole value stream has to be involved when you say, I'm delivering enhancements or I'm doing a product maintenance or I'm doing a release. All of this have to be involved. So it's not just the team who are developing it becoming at that. So these are the two definitions I want to put before you when we ask this question ourselves. What do we mean by becoming business at that? So now having said that, what is business at that? Just to be familiar with stage-gated approach, what we have essentially is it's coming from, the pre-stage gate era was functional silos. I think all of you know this picture. You had, yeah. Exactly. When the portfolio is agile, your business becomes agile because you get feedback back to so that the right mix of projects can be chosen. So you need feedback in terms of finding what to build and then putting it out, whatever. Yeah, what you have said is correct. Yeah, that's how we also defined it when we started it. So we have been agile for quite some years for maybe for more than seven years. But then we discussed when we understood that one aspect of it is to move up at the program level that moved to an enterprise level. That is where we started this experimentation as to how do we do that? So will scaling agile frameworks help us? Yes, they do, but do they fully address it? Because we are in a constrained environment, you have stage gate, still how do we balance these? So that was the kind of hypothesis we were looking at and how do we validate these hypotheses? So that was the understanding. So this predates the stage gate approach where you have functional silos. I think all of us are clear. It's kind of throw and catch over the wall thing that we do. But by the World War II after that, we know that because of the defense and a lot of high defense contractors coming in, you need to have a phase gate approach. And in fact, while this process, there's a considerable amount of risk control that's possible with this kind of process because you have the cross-functional discipline that's coming in and the collaboration that's there. But along with that, it's relatively slow. And also it doesn't follow the natural flow of value. It doesn't help with the natural flow of value because it's all of the cross-discipline together and time to market gets greatly impacted if you use this approach. But nevertheless, it is a significant development because it is a typical phase gate approach that all of you know. No, this happens at the development side. So what I was mentioning before here, so there are two ingredients here. One is the agility of the portfolio. How do we increase that ability? One is to give constant feedback back from development. Stage gates happen in the development side. So that is where the stage gates are. So that has been historically that's very important because that's when cross-functional collaboration happens when you develop a product. That's how it has been developed. So this case study only addresses how we approach stage gate. But to increase the flow through portfolio and to development and feedback, you also need to size the increments in a good way from the portfolio so that the pipeline is not choked with a lot of things. If the development takes a lot more time, the pipeline increases and the distance between the feedback and the portfolio decisions take a longer time. So in this study, we are only addressing the stage gated part which is part of the development. So this is where I was. So there are very good things about stage gating. It's important. But if you mandate a very strict adherence to it, there are bad things that could happen which will actually hamper your business agility. So we are looking at what are those things and how do we balance it? Because once it's important to break the silos and get into a stage gate approach where you have cross discipline, but once you've attained a certain flow, further improvement would need a significant amount of work because again people are tribal in nature. We come together as a cross-functional team and go back and again marketing becomes marketing and then again you come back for a meeting. So we go back to our human nature that we are still tribal. So that's why we need to address it differently. So these are some of the advantages that we have with stage gate. There is fundamentally nothing wrong with stage gate. It's actually very important. And if you have barriers, then this is the best mechanism to bring people together and move things. So for example, if you look at cross-functional, oh, okay, I'm, okay, all right. Looking at cross-functional collaboration, I've put some six points here which has pros and cons when we get into, one is cross-functional collaboration. It's very, it's an excellent way to break down barriers between disciplines and come together, collaborate and work towards a project. So cross-functional collaboration is an important way how stage gating helps us. But if you take it too far, once you are in the rhythm, then you go back to your own ways because you come together for a meeting as I was mentioning back and then you are in your silos. So further improvement, further team collaboration, it's difficult to achieve. You need to really, another advantage is risk management. Doing stage gated approach, you really know what are the steps that you missed and it's easy to find out whether the project is at risk or not. But if you keep practicing it over the years, you become very risk-averse. Then your innovation capability dies down because you know these are the steps that you need to follow and the project has to, all of the projects gets killed in the way. Only those projects which are really good will come into it. Then you're killing yourself. So there's a risk-averseness to, you build a risk-averseness, the culture becomes a little more risk-averse. So you have advantages, it's a kind of a double edged sword. Same thing with understandability. In regulatory, for example now, medical business that the documentation is actually fairly complex. But stage gating helps us visualize the whole structure of documentation. What needs to be here, what needs to be here. So it's pretty simple and straightforward, although by reality it is fairly complex. But then the other side of it is, it becomes a straight-jacket approach. If you need us, if it's a straight kind of a project, if you want to reduce it, you tend not to do it, because you're always been practicing this kind of a documentation approach. So it has got pros and cons. Take the comprehensiveness. Stage gate approach gives us a way to prescribe processes in a very good way. In this phase, this is what you need to do, this is how you should do it. But then in the longer run, the more details you're getting into, it amounts to a lot of redundancy and more rework that happens. So that is another two-sided thing. If it is used as a light touch-weight process, it's very flexible. But most of it, our experience was it was difficult to actually change what is mandated because you follow the rhythm of the road. And speed and efficiency. So stage gating because of its serialization and flow, the natural flow of work is restricted because at gates you restrict. So these are some of the advantages and disadvantages. So there are significant advantages of using it. So our question was how we looked into it was when we had the organization level stage gating process, the different project categories. So we have different business models. For example, software only product. Software as a product or software as a service. Then you have embedded software inside devices. So the project management lifecycle needed for these different categories also could be different. But as per standardization, we have one approach to stage gating. But categorizing it based on the different project management life cycles needed is again a little bit of you need to do that separately. If you have only one common process, then you force fit yourself irrespective of what kind of business model you're following. You have to force fit yourself into this kind of a stage gating. So this one size fit cannot fit all. So that was another reason. I think that's there in the slide. So why should we, there are different project categories, but one approach to all of it. So this also actually reduces your enterprise agility because of it's not fine tuned towards different business models. You have, as I was mentioning, devices with embedded software, but you have standalone software products. And then you have solutions and services. So one size does not fit all. So with all of these aspects in mind, what do organizations do? We found that what typically happens is you run iterations between these gates. When you are in prototyping, you do in an agile way. Then you come to a gate and then you pass the gate and then you move to another phase and then you do again agile. So this is, as I was mentioning you, this is the beginning when your team becomes agile. But then the program, not the business is agile here because you're still doing the same thing. Only thing you are moving it in an iterative way. Another disadvantage that we found was because of the gates coming there, the 100% it's a big batch process. 100% of the batch have to move. So 100% moves from one to the next one and to the next one. So the whole batch is moving. So where are we having this? There's a high limit, I mean high work in progress. So then what happens is if there are smaller items, it comes and waits at the end of the gate. There's a queue, there's a queue that develops. But there are other things which takes a longer time. So there is, if you follow a 100% completion batch process, it's a big batch. So these keeps happening. So then we are team agile, but we are not business agile. So this is one of the things that we found out. So then how do we get this past? So one of the things that we did is to conclude, this is something that we figured out in experiment that we have the product development with the flow directly from the portfolio to the development. So what essentially is you need the feedback to the portfolio so that they can choose the mix of projects that they want. The mix could be either to deliver or to discover what needs to be built. So keep the feedback flow always ongoing. So that is the first step that we were trying to find out. And secondly, as a part of it, the release management process is separately done. It's a decoupled from the main feedback that needs to happen. So the portfolio prioritizes and gives the feedback back. And at certain moments in time, the milestone and the gates are about how mature are we in terms of the risk reduction, in terms of market risk or technical risk or the regulatory risk. In terms of the risk reduction, how mature are we? So the gates are a kind of agreement where what kind of uncertainties are still there, how much of uncertainty I've reduced. But the feedback mechanism is still active. The feedback is not touched. So this is something which we experimented. And we did this and understood that this actually gives a lot of flexibility in becoming enterprise agile. So the doneness, anything related to regulatory doneness is part of the development itself. So you make sure that your uncertainties are in every cycle of increment you really assess that. And your technical debt, your regulatory debt, or your compliance debt is kind of you make sure that that is not there. Otherwise you have to keep improving that every increment, every sprint. But then you have the feedback open from portfolio. Portfolio can choose to keep changing the priority. But this release management comes separately. So this was the experimentation that we did. And I thought this is something that the insights that we got from this study. And we validated our hypothesis that it's indeed possible to become, mix both the worlds, the best of both worlds. So that's 15 minutes. I thought I would stop here and take some questions. Yeah, so here there is no queuing here. The work continuously happens. And there is a feedback to the portfolio as to what needs to be done next. And there is no gating mechanism in the below. You don't wait because it's milestone driven. Every sprint is a milestone. Every increment is a milestone. You look at what has been planned and what has been achieved. So you look at the debt that you carry and you clear it up in the next sprint. You keep prioritizing it and doing it. And there is no stopping for gates. Like the previous slide, you have four different phases of the project, right? Which you are doing in through these gators. That's like gate one, two, three and four. So if you transpose this on this, this step here, say G1. Correct. So the defined build verify happens continuously. So all the phases gets imbibed into the whole activity. So the V model, the model collapses into the end-to-end functionality getting tested and built. So that is the, yeah. In say release or R 1.0, in that these G1, G2, G3 will have all those four steps, all those four stages. No, the nature of the gates, the spirit of the gates will change now. The spirit of the gates is how, what's our uncertainty now with respect to what we started and what we wanted. In terms of have you reduced our risks in terms of technical or marketing, whatever be the spirit. So the spirit of gate is to agree that we have reached that point. But the work continues irrespective of that. So this is really what happens. But we just pull everything together, stop it, go for a review. Then again, stop. Instead of stop, start, stop, start, this continues. Is it like last slide is more of a waterfall which you now move to Agile, if you see it. We cannot go away from the stage gates because those gate things are needed because of the constraints of certain expectations from the market if you're in a regulated industry. That's why I said we have to mix the best of both worlds. If you remove it, then a lot of things will not happen. Yeah, thanks. So there are advantages. So the, you know, I just have so many questions about this, right? Because this looks like waterfall to me. Yeah, yeah. And so I keep wondering what, there's so much work in process here. And so my question is this. So the regulatory agencies are likely imposing some of these gates. Is it true? No, regulatory agencies doesn't impose any gates. Okay, so what, so you talked about the advantages of these gates and yet their gates are antithetical to Agile, right? They inter, unless the gate is actually going to a customer and getting feedback to you, you're not really getting rid of work in process. You're just accumulating it over time until you reach the gate where you do touch the customer. So that has been a change here. Yeah, that would have been the case if it was the complete batch moving forward face by face. That's a typical full batch process, going batch by batch. But here what happens is that has been broken down. There is no more, there's a separation of the gates and the work that happens. I see, so we look at this lower one, which has G12345. So is that happening in a single sprint? No, that is asynchronously happening. This is what happens continuously. So there's no sprints? Yeah, this is a sprint and the work happens here and the feedback goes to portfolio management. I see, and the G5 is where you actually touch a customer. Yeah, the G5, I've just put some arbitrary gates here just to give a notion, but it could be, there are some constraints, maybe for example, one gate you need to make sure that all your product is baseline. You need to do a system validation. There are some constraints which the regulatory laws put on us. So you need to stop at some point in time and then do this one cycle and then only you can release it. So when that doesn't impose a gate, that's something which you need to do. But how do you manage it is through a gate. Or you could figure out how to do it continuously. Yeah, as long as this team, whoever is in this team can show evidences that you can still manage it and show evidences that's good enough. Were you able to convert any of these so-called gated activities where you had to stop and then do something? Were you able to convert any of them to a continuous deployment style process? Yeah, yeah, so exactly. So that's, there are two aspects to it. The transition process involves reducing the number of gates first of all. Maybe an organization which moves from a siloed thinking to a phase gated approach, they might start with eight gates. As the transition it becomes four gates or three gates. Then finally you approach a place where depending upon how willing the market is to take something, you get into a continuous delivery mode. And that there are constraints on the, on these, how- Were you able to move any regulated things into this continuous mode? Okay, there again, it depends on the level of concern of that product because there are different categories of the concerns. With the concern, for example, if it's for food and drug and FDA, they have a level of concern, concern three concern ABC classes. Or if it's European, there are another set of classes. So for least level of concern, you can take the least burdensome approach. But if for a higher level of concern, you can't take the least burdensome approach. So you always have to look at the highest burden approach and then reduce it for depending upon the concern that you have. Were you able to talk to any regulators and change or adapt, working with them, adapt their processes so that you were able to do, to eliminate some gates? Yeah, yeah. Yes, when we had this initial process defined, to suit this HLB of working, we did get a couple of FDA consultants to kind of review it and they're pretty happy with it. And as Vinit mentioned, regulations don't say that you have to have gates, but of course put certain constraints and the way to achieve those constraints or to beat those constraints is through gates. That's how we devised it. So in fact, at that lower level, or we take credit for everything that we do. Nothing is throw away there. Like in fact, if you look in the healthcare regulations, it is expected that when you make something available as a release, whether it's for a beta site or whether it's for a customer, you need to run a full verification cycle on that version. Now in agile, you don't do that. You do it incremental testing. Now we have kind of built in in the way that we take credit for the incremental testing that we do in the design build verify, but then we still meet the requirements of the FDA in a way that we show evidence for it. So the gates are not that actually you do anything. You take credit and formalize that in a way with approvals and signatures and stuff like that. So that you can evidence that this is how we have done it. And a couple of business units, which have adopted this kind of a process have also gone through FDA inspections in US and we didn't have any findings. So that's a proof of it. Yeah. Okay, one last question. One more back. These are just typical gates that I've just put. This is, yeah. Yeah, here are you suggesting that we need to incubate some of these states here during our development phase itself of a product? No, no, no, I'm not trying to do that. And we're just saying that in the way which stage gates are designed, it's a cross-functional collaboration. All the different functions, development, marketing, customer service, everybody needs to come together, collaborate and do things together, and then you come to a gate, you decide where the management of the business decides, how the risk being reduced, are we willing to go forward, should we invest into this project or not? So that's the idea of stage gates. The problem with that I was, it's very good because it brings collaboration and it becomes a joint decision as to how do we move forward. So I would say that that is important, that's needed. But how do we bring, as I was mentioning, this slows down the time to market because of this approach, and also over time this becomes mandated and we will not improve further. The teams just come together as part of the cultural ethic. So how do we break that paradigm? So the paradigm that we are saying is you always have touch with portfolio and the feedback. The development keeps continuously happening. And the doneness of what you do is actually measured every sprint. So it's basically the definition of done. Yeah, definitely done. Bringing in the cross-functional. Your definition of done, the cross-functionality and the regulatory doneness is coming back into the development. Rather than putting it at the gates, we bring it down. So I would call this as a hybrid, a combo of... Yes, yes, it's a hybrid model because, yeah, because that's the way you govern the work because you're looking at different complex projects. You have to have a mechanism to govern but still we light and flex. Thank you. Okay, thank you. Yeah.