 and within Philips, I see very many familiar faces around that, right? And I'm going to cover quite a bit of stuff in the next 20 minutes, probably some of those things. The way I have kept the slides is to be more self-informative, right? At any point of time, do reach out to us in terms of what we have done. And this is a work that has been done by a transformation team within Philips. Many of my transformation colleagues are there with me, right? So I represent them, okay? Just a small introduction about myself. I'm responsible for running this agile transformation program within Philips. We started this journey somewhere in mid of 2014. We had an external assessment from McKinsey, where they indicated the top three issues that are there, right? So the first one was, from the time we write a software code to the time it is available, right? In a system or an in-customer environment, it takes about 18 months, right? From the time you write your software. From the time a customer needs a change to the time it is available back to the customer, it takes about two years, right? So, and then we had some quality issues and things like that. There were pockets of excellence that is available within the organization, but is it getting scaled up to the other parts, right? The same teams continues to do more, but is it getting transformed to the other teams? So these are some of the key things that were presented back to us by McKinsey. And then that's where we looked into different models that is available in the industry. And then we did a good evaluation about these models and we decided to go with many flavors of agile, primarily with the scaled agile framework. So that's in a nutshell, the start of this journey. Okay, so I would cover about this, the program and some of these activities I'll just move over here. So this is the structure what we have put across within Philips. So if you actually look here, basically right starting from the goal, what is that we want to do, right? So having the software in a predictable, fast and agile way, primarily in simple terms, apart from the good English that is written over there, it is basically look into time to market and quality. So these were the two fundamental objectives of this particular program. And this is a transformation program where we said that we would touch about 8,000 people of R&D spreading over to other divisions like hardware, mechanical, electrical, then moving on to HR, quality management system because ours is a heavily regulated industry, right? So what is the structures that are needed? Associated with it, starting with, you know, how do you build the practice? What type of trainings do you need for the organization? What is the governance structure? Who is going to be involved? Who is the coach who is working, going to work hands-on? What is the cultural transformation that is going to happen in the organization? How do you transfer, share, learn, disseminate practices? So that is over here. So far what we have done, okay? So we have good results that are coming up, which I would talk about in the next slides as well, right? So we have now, first, fundamentally, we have decoupled releases from development, okay? So if you take a platform team, we make a release once in three months. If you take software-only teams, we hit the market once in six months. If you take the big iron machines, we hit the market once in a year. Primarily, you know, the interview, bed monitors and things like that because the hospital needs those releases only once in a year. So the development cadence always goes through and the anytime release, at any point of time, you want to make a release that is very clearly structured and taken. And at that point of release, now we also have the FDA requirements also taken care of, okay? So that also has been merged into the system. Currently, we have about 25 agile release trains that are running in the organization globally, right? So we have currently about 15 or 16 locations in the globe where the agile release trains are running. Many of them are distributed agile release trains. And if you take the individual number of RPEs or the program increments that has been done, we have touched about 76 RPE events so far. And by end of this year, we would be somewhere about 175 agile release trains within the organization. And we are also now, as we speak, we are cracking the systems part of it. There are three system lead deployments that are running, basically with the safe 4.0 with electrical, mechanical and all the other hardware teams together in the same agile release train and with value streams being implemented. So that is the current work that is happening, okay? We have touched about 3,000 people in the business so far in SAFE. We have trained about 2,400 people. We have about 50 SPCs in the organization. The way we do training is that these are the SPCs go and do the certification programs and other things. We have roughly about 900 plus certificates primarily on SAFE Agilist and the SPM PO, right? So these are two certifications which we focus on and then to the leadership, we focus on the SPC sessions, right? And these people go and further populate this information across, right? So there were few recognitions. We won the prestigious internal speed award. So this is an award where about 30 teams globally in Philips participate and we won that award. And then, you know, many more conferences and other things where we have won and shade what we have done. The model, how do we, what is the strategy and approach that we have done? The Agil release trains what we have scales up with about 40 people to a maximum of about 120 or 125 people, right? So that's the number of people on the Agil release trains what we have. And how we do this, we start with information called as diagnostic, right? We go to the business and find out what their pain points are. This is not an audit. It is basically a series of interviews with the leadership team across the organization right to the team level to find out what is their most important pain point that has to be solved. For example, this could be like, you know, my whole validation pipe is show, okay? I am not hitting the releases to the market. We are getting a lot of issues with respect to regression, right? So these are some of the very clear pain points, continuous integration. We have something like 200 tools within the organization. How do we enable continuous integration, right? We look at those very clear pain points and come with the solution design. So that is what it is all here. And then we just move the teams across the journey starting with basic Agile. In basic Agile, what we do is primarily we focus on Scrum XP and Scrum Initiatives. If it is a maintenance type of a project, we look at Kanban for them, okay? And then we scale up to safe, then the continuous integration, DevOps, and the delivering into the production. Okay, some of the key success, the next two slides are going to be a bit crowded slides. I just want to spend a minute here. The first statement from Deming, yes. It is very clearly recognizable. Only management can change the system. The second one is from our senior vice president, sponsor Mr. Diego Oleg, where, you know, when we started this program, right? He said to us, any transformation program is successful if you actively seek and solve business problems, right? If you just implement this safe as a framework like a CMMI or a CMM or a model, right? Again, we are not going to be successful. Go back to the business, find out what their problems are, right? And try to resolve them. The second statement he made was two years, three years down the line, right? Our team will not be remembered for the work what we do. But the cultural change what we do in the organization would remain for next many years to come, right? As a team, we would move to the next transformation and to the next work, right? People will not remember, right? No, X did this work, why did this work? We always put the business in the front, okay? So we say to the business, you are leading this transformation change. We are not leading, we are just an enabler. So this has been one of our very key success points and because there is no longer, like you know, should I take the credit? Should you take the credit? Who will own this, right? So those type of discussions are never on the table, okay? So these two are pretty busy slides. What we have done, we always start with the executive leadership. It's a one-day session where we tell the leadership what to expect when the teams are in agile, okay? We tell the leadership very clearly, don't look at daily status reporting, okay? You are all in agile. Can you send me your status report for the day, right? So we make those statements very explicit to the leadership and that's what happens here, right? We have something called as agile software playbook from the deployment so far. We have collected about 300 artifacts that has been done and then everything is centrally deposited and stored here. Any person in the organization can go here, refer and then he comes back to the community of practice to know, right? So what to learn from it, right? How do I decipher this? And also, we have globally about 20 coaches as part of this transformation program plus another 20 coaches from the business because we work with them for some time, transfer it back to the business and then we move to the next business line deployment and then people come back to the coaches and ask for how should we do or how should we continue this, okay? Here again, we saw some good aspects in the previous from Fabiola, right? Some of the people who were here, right? So these were some of the things I, what we do in HR, right? HR is linked with this transformation, right? So they are not outside. We are even thinking about how to move from the traditional appraisal system to a team-based appraisal system. We have created job families, job catalog in order to support this safe journey, right? So those things have been enabled, right? So what are the behavioral changes or the cultural changes that is needed in the leadership that is available, that is taken care of, right? Change management, a key element that would actually impact about four layers in the organization. So you have the team, you have the middle management. This is where we had the most challenges, okay? So once the team started getting into this agile way of working, they started questioning the, especially the managers, what we call as the project manager and the program manager, right? Okay, I mean, sorry for using the crude word, right? Let's not have intermediaries. Let's not have postmen's, okay? Can we talk to the content owner directly? Okay, what should I do in order to talk there? Because just a person to say that or pick up some information from there and pass it on to the team, we don't need you, right? So they started moving into the next roles, okay? So this is one of our key changes that we factored in, okay? And then between teams, right? Between, if you are in a platform team, right? So how do you work with a product team? If you are, if you need a hardware, okay? How do you work with the hardware team? So those people were brought into the agile release trains. If you have to deal with a UX engineer who has to give you the information and feedback, they were brought into the agile release trains and they welcome the change. They wanted to be part of it, okay? And then the leadership, which we explained. So some of the results, so the work, what we did, does it transform in two results, right? So as I said that we were hitting the markets once in two years, right? So in, I just picked up some sample, the releases are three to five X faster, which means that money starts flowing in back into your kitty as soon as you make your releases. What you used to realize once in two years, now for the features that has been delivered till now, you start realizing your money, okay? This particular one, so this is a project which has about 17,000 test cases, right? And they have something like 17 to 18 product lines in which this particular platform releases are taken. And then they have started hitting zero regression, which means that once in two days, about 17,000 test cases start running in the system, okay? Is it translating to what the customer sees? Because as I said earlier, look into, right? What is the problem and what is the solution you have to? You are going to offer, right? Just look at some of these statesmen, right? We never thought Phillips would come such a long way in delivering these features. Chairman of Department of Radiology, right? Are we listening back to the customer? So a direct statement, okay? And then, you know, somewhere here, your development teams did an amazing job. Okay, so a direct reflection on what is being done translating into results. I just tried to map this with the, like, you know, what we see in the safe slide, right? Feature cycle time reduced by 60%. We are able to make releases once in six months, okay? So time to market, we are able to address quality. Yes, it has improved significantly because if you have so many bugs in the system, you cannot make your releases. And this is where continuous integration also plays a very big role, right? Starting from your code checking, starting from your review, the unit testing, the automated build tests followed by functional tests and then leading into automation suite of about 17,000 test cases. So this is where it is showing to show the impact. Last year we measured what is the savings out of this particular program. So this is given by our finance, right? So the savings is about 10 million euro, right? So direct cost translation in productivity, okay? And then this is most important. We have few videos also, of course. I don't have time to play it now, where after just an RPE event, right? The team just did a, called us a train dance, okay? So very clearly you can see, right? In fact, we wanted to pass it on to Scaled Agile Academy as well, right? This is what we do in agile release trains. So the whole team of about 50 people just did a train dance. So very clearly, right? People are, especially, you can see the difference. Of course, all the 100% of the teams have not moved into agile. We see the difference. The teams which are in a safe way of working to the teams which are yet to migrate, very clearly the pressure situations, right? So people are coming in. So some of the, just to give a summarize, right? We said that first we start with the diagnostic. We get to a leadership involvement where we say don't look for daily status reports, right? Then we learn together. So we just take the entire team through a scrum master coaching, product owner, release train engineer, development teams, right? So there is a training under coaching. The coaches are associated with the team for about two program increments, right? For six months they do hands-on coaching to the whole team. It's not that we just come train for two weeks and then we move over or come over there after three months to check what is the status. So they are with the team, okay? Then we move over to the first agile release train. So typically, you know, our experience with the first agile release trains, we get about something like 55% to 60% predictability. There is a lot of chaos, okay? People don't know what to do, right? People, they don't have roles and responsibilities very clear. And consciously we don't make it like only after 95% of all these structures or results we will get to an RP. Probably that will take about one year, okay? We, from the time somebody is interested, any business is interested in safe, typically we take about four weeks, okay? So that's our lead time. We work backwards and say that four weeks from now we are in your first agile release train or max six weeks, okay? So that's how we move forward. Collaboration, straightforward. Then you know, this is where the HR and the leadership impact change, right? And then, so this is how the loop is. I just want to spend a minute here. So this is what we figured out, okay? So if you want to change the culture of the organization, right? So what we thought, we just, you know, analyze this. First, we have to deal with the behaviors, right? We look at, for example, you know, command and control as a behavior within the organization. So that is there, right? A scrum master, a project manager has moved as a scrum master. So if he has to come out of this typical command and control methodology, right? So then, you know, we work with them. Three or four scrum masters start exhibiting the new behavior. So they actually form a pattern. This particular pattern is observed by all the other scrum masters, product owners, release train engineers in the organization. And then that becomes an habit because no longer people see that what is this team is doing differently, okay? And what we are doing differently. How is that they are able to see success? What is that we are missing, right? So people start imbibing those habits. Habits leads to a cultural change. So if you want to change the culture of an organization, the first aspect you need to address is behavior, okay? Also just giving two years before, we never knew about SAFE. Philips as an organization, we were never there, okay? Now SAFE is becoming a culture in the organization, right? So if you want to change culture, bring changes to the behavior first. So are we 100% successful in this, right? I would call it as a learning journey. Still there are more things which we need to do. Some of these things, for example, leadership engagement and other things we have addressed it, but the other aspects, you know, we are still working on it. Tooling, we had about 200 plus tools in the organization. Continuous integration still continues to be a challenge. We have given a couple of top recommendations in terms of tooling. For software only, we recommend TFS. For a systems only, we recommend RTC, IBM, RTC suite of tools, right? We are also looking at Atlassian, right? Into the whole aspect. So for new businesses, if they want to start with any other new tool, our recommendation is don't do that, okay? Please don't go into that direction. Otherwise, again, you will hit a new problem, okay? Change management, right? There are parts of the organization which has changed. There are still parts of the organization which we need to change. As I said, this is a four-year program. We have covered about 32% of the organization so far. We have another 68% of the organization to go forward which would write, you know, this program, as I told you, will run till 2018, 2019, right? New roles and responsibilities. Yes, we have the job family catalog, right? So we have invited Fabio also for a talk in our organization tomorrow, right? We have to take some of the powerful messages which she gave, right? Fire fast, right? So these are some things, you know. So the message what she gave in the last was higher, slow and fire fast, right? So how it would, because we have to evaluate, right? How it would work in an organization which has a cultural history of about 120 years, right? So if you have to bring these changes, it is not something like, you know, you can do something today and tomorrow you will see results, right? So that is another challenge which we need to focus and address, right? So organizing themes around values versus silos, right? You know, now look into the end-to-end value that would be generated. Move away from the silo mindset. I will do only for electrical department, some work in Scrum, okay? I will do some work only for my development team with respect to SAFE. I am going to do only localized SAFE, right? So these are some of the silo mentalities which we are breaking and then, you know, making them people to see the end-to-end value in doing these work, right? And then finally, Enterprise Geizen where we are able to get improvements as a whole, okay? How can we make the release cycles much more shorter? Okay, now, and also this, the whole change is moving towards as the development teams have started adopting this, the pressure on the marketing, the product management, okay, that is becoming higher now, okay? Because we have something called as the GTM or the go-to market, the pressure on them is increasing currently, okay? Now, the development is ready with all the information and needed contents for the release, right? How can I give this to the market, okay? So we have food that is cooked in the kitchen, right? How do you take it out and serve, okay? So basically, the development teams have moved out of the critical part and then the next in the chain comes into the critical part automatically, right? So as a message, right? This is also, I say, very frequently, okay? Either safe or any other methodology or a model is not an end goal in itself, okay? The end goal is basically to realize the value that is needed for the end customer, okay? So these are means to achieve that end goal. And now if you ask me that, you know, did safe work for us, the answer is a clear yes, because using that as a vehicle, are we able to address the needs of our end customer and our stakeholders, right? I think, you know, we have some good success stories to share with all of you. Questions? Yeah, so when we actually started, right? What I mean by inconsistent teams over there is that two problems were there initially. There were teams which are actually doing a waterfall way of scrum, okay? And there were teams which are actually in pure waterfall. To give an example, a project manager approached me and said that, okay, I am following Agile, I am in scrum, okay? I want a coach with you or you can come and help me. Can we make a plan together for the next 52 weeks, right? So, see, I mean, how do you address this? These are typical challenges, okay? He says, next April 2017 is my release. I want you to help me to make a plan for 52 weeks, okay? Then, you know, bring them, right? You know, first educate them, bring them, because it has to go through a big cultural change, okay? So those are like, you know, these were some of the second is on tooling, okay? We have started everything, but productivity remains the same. Nothing happens over there. Because if you go and ask the configuration manager, he says that, you know, everything is working fine. If you ask the developer, he says that I have checked in. Okay, and then what happens next in the chain? It gets done. So consciously, you know, that's why I said the diagnostic piece is very important for us. Consciously, we look into what is the problem for that particular business and then what is that we need to solve for that business. And we involve the leadership there. Yeah, it's a good question. See, more than looking at that way, how many SPCs we need, right? One of the, when we said that the coaches would be available with you for some time and then, you know, we would move on. So we said that any team which has 40 members plus, right, because it is not possible that for a long duration of time, you can have some external consultants as coaches with these teams. So we said that we will identify a person within your team to whom we will ask him to go through the SPC certification course and then he would be the agile change agent and champion within your department. So as coaches move out after six months, the whole work that is being done is transferred back to this particular SPC. Okay, so the person is, for example, all our RTEs are SPCs. So we don't look at somebody, you know, to come there as a special role for it. So a product manager is an SPC. So likewise, you know, we put them and then we bring them into our communities of practice and then we say that these are the typical challenges which you would face, right? You know, the whole repository of learning is also available if you actually look into that, the agile software playbook, practices playbook and then, you know, we bring them together. Absolutely. Yeah, and I'd like to start with them. Yes. Very well. Rather than, you know, trying to identify a role who would continue this transformation journey, these are we giving it to a senior person who is already available, make them aware of what this work is all about and then giving it to them. Yes, we did it. Maybe I'll take that question during lunch and also my whole team is there who were with me for that evaluation, right? You know, we will take it in lunch. Yeah, one minute, just his final question because very tough to be very honest with you because for a long, they immediately jumped in us, I will become a scrum master. But as a scrum master, right, you know, they were actually doing the role of a project manager, right, when our coaches went for the standup meetings, sometimes we have to hijack the project manager from the scene, which we did it, okay? And then, you know, we just hijacked that person and said that, and you know, we said to the team, one week, the scrum master is on leave, continue. Initially, the resistance was very high from them, okay? In terms of responsibilities, you know, if you look at it as a scrum master, right, you move more towards a servant leadership to a facilitator and this is more on the behavioral aspects. The other part is, in Phillips' work, you need a lot of technical people, especially understanding the medical domain and things like that, so otherwise the team is not going to respect you for that. These project managers, they already had those qualities, okay? So the only transition what we need to do was remove this command and control and the, you know, becoming a daily status manager role from them. So that is where we focused, a role-based coaching.