 We have achieved really amazing results, and these results I want to share with you. I will not explain you how you should do or what you should do exactly, but I can share with you what we did, and you will see also the results which we got. And that's for me really something what I'm excited about. I'm excited about the results which we have achieved, and I want to share them with you. So, let me start. What we will talk about, we will talk about the situation in which we were, and how did we actually, and discovered, okay, the problem is existing, which we have to resolve. Then I'll touch the problem for a moment, and then we'll come at what did we do, and what was the effect of that. So, no theory, almost. So, it's about me, I'm Guides, I'm working now in Germany, in south of Germany, Munich, which is extremely nice region. This is the kind of view which you can see from almost my office, you have to still go out from office to see that a lot of forests around mountains, so we can think and come up with something really great, which we also manage somehow. So, I'm married, I have three children, so somehow I have to also divide the time, children, work, work, children. And I'm working with the European Genomics already since almost seven years. It has been some time, I have come through also a lot of challenges, and at the end we have reached one state which we can call that, okay, we have achieved something. So, let's look. Eurofins Genomics is the company which is global company, it's part of the Eurofins Scientific. Eurofins Scientific is having 40,000 employees all over the world, multi-billion business. We are rather smaller part of that, but we are still a global company who is doing business in the area of genomics. So, genomics, that means genetic analysis and production of genes. So, we do the oligosynthesis, gene synthesis, we do the next-generation sequencing, we do the classical sequencing, we do the microarrays. Basically, it's all around the discovery what is inside our body, how to use it, how to produce drugs for us also, which could even cure the illnesses which were also considered as uncurable in the past. That's what we do. And as we do a lot of this, we have also the IT organization, which is also global, mostly global. We have the development center here in Bangalore, and I'm really happy that we decided for that. I'm really happy how good and how professional our organization is working here, how good are the people whom also we are getting. And it has been a real pleasure working with India in the last, okay, I have been working with India even before that, so like 12 years now. Besides India, we have also a few more locations, and we have a whole bunch of applications which we are using, starting from the production applications which are manufacturing, execution systems that are laboratory information systems, e-commerce platform, platforms for quoting, for support processes, for ordering processing. We have, if we count all the applications which we have in organization, it will be around 40 or 50 applications. That depends which ones you count as real applications. So software is really a core in our business. We have highly automated industrial scale processes. We are producing the samples overnight. It's really express. If the patient is on other side and he expects the medical treatment, he has to get answer very quickly what exactly is a type of cancer, for example, which he is having so that the treatment can be started immediately. So it's really the software is a core. We have to automate everything. And the customer also expects that the results from what we are doing are delivered also automatically and in the form how he needs them so that he can integrate in their processes and again wins the time. The time is everything. There is a second part which is at least as crucial its quality. You see, we are producing information and we are producing also the substances which are afterwards either used for producing the drugs or directly placed into the patient. So we have the huge responsibility for the patient, for the health of the patient, for his life or death. Of course, because of that we have to ensure that the samples cannot be mixed, that we cannot by accident analyze the wrong sample and give the wrong data. So the quality, the quality is really before or after the speed that depends with exactly which customer you are talking about, but either of two is the crucial part. So how do we ensure? Because the industry knows that and there are other companies also who are doing this. So there are multiple things what everybody is doing. It's CMMI, CMMI everybody knows, right? The Gump 5, it's 350 pages of approach, description on high level how you should program and validate the software. And then it's extended with many thousands of pages and exactly you should apply these generic rules. Then we have, of course, there's industry practice always QA with testing, analyzing, validating and ensuring that there are no bugs. And of course, we also applied most of these, maybe not everything 200%, but we also are CMMI level 3. We are doing the Gump 5 based software development. Yes, we are also, we were using the test automation. The QA team was responsible for ensuring the quality of the software and regular internal and external audits also were happening. Our customers were coming to us and checking how do we create the software? What are our lab processes? These are very big pharma companies, right? They have to ensure that the company which is delivering the data to them also of highest compliance. And of course, measuring and following appropriate KPIs, defect density, the defect leakage, all of that, what we are doing. So, and yeah, of course, it's ISO 13485. It's special ISO for the medical devices which software is also considered as medical device because we are using it for producing the drugs which will be placed into the patient. The Gump 5, the GXP, the good manufacturing practices, good laboratory practices, good clinical practices, under FDA, clear certification and so on and so on. So, it must have been of the great quality, right? There shouldn't be any defects whatsoever. With all of that, what we are doing and still, what do we saw? What do we see there? We observed that our defect rate is growing. It's a little bit fluctuating, but it's growing overall. We have faced the very lengthy release cycles waiting for the releases. Then the production says, oh, it just clubs the efforts for the validation. Let's make even bigger release so that we can save some time on the validation. It was like a cycle, a cycle all the time and the revalidation effort for everything that comes into the lab. And we were planning also the releases and also the rollbacks so that if we have delivered bad software, it can be rolled back easily and the support effort was only increasing. So, we see also here these lines are fluctuating, but it's going up. It's defect density, right? So, it's far above whatever zero. It's above even the yellow line. It was defined as still acceptable quality. So, that's where we were. Now, what about agile in that situation, right? Lengthy release cycles, quality going up and down and combining more and more into the bigger and bigger batches. Of course, we were still doing some scrumping, right? Some sprints and retrospects and all of that, but we were not agile anymore. We were in a waterfall world running just with some sprints. Okay, sprints are cool, but it's still waterfall. So, agile versus compliance. It's like, okay, it's very simple. Either you are agile or you are compliant. So, on one side we want to be agile, but we have to be also compliant. So, we first do the compliance and then whatever is left over, we can do agile way, right? So, we do all the processes and validations and contracts and following the nice waterfall plan and then we do all of that in agile way, cool. But, well, it's not so great. Then we asked ourselves, why? Why we want to be agile? Okay, we want to be really fast. We want to also be the first ones in the market, right? At the end, all what we want, we want to beat our competitors and earn a lot of money. That's what companies do, right? And because of that, we want to be also compliant because the pharma customers are having a lot of money which they could give us. So, we should take that money. And because of that, we have to be competitive on the market through compliance. So, there is a problem to do. So, agile versus ensure quality, which is at the end, sometimes it is not so much about ensure quality than certify quality. Because we saw the quality was not there, right? What if that quality fluctuating all the time meant for ensuring quality at the end? It's just all the check boxes which you take to say we have done everything what we could. Sorry, guys, if the quality is not there, it's not there, but we have certified we have done everything. So, we understood there is really a challenge, but what to do about that, right? Okay, understanding that we have a problem is good, but what to do about it? No, there is a conflict. So, I thought again about the quality. What is the perception of the quality? What is understood with the quality and with the defects? At the end, bugs are normal, right? It's part of software. Somehow, whatever you get is having some bug here and there, but it's okay, right? It's part of the process. And fixing all the bugs is anyway very expensive, right? And then you will invest a lot of many years in understanding really rechecking the whole software and ensuring that it's really of the highest quality and no bug is escaping somewhere. And we are doing already extensive testing after each sprint. We are doing all of that. We develop, then we give them the QA, QA is spending doubles the time for testing, then we give to production people, then they spend a few more months is whatever on validation at the end still. The defects are flowing like continuous flow. Always get some defects. And also, if you speak with other people, the humans are doing mistakes, right? We are all humans. I do mistake, you do mistake. We all do mistakes. So what's such a big deal about that? But at the same time, what we see is the defects are not part of velocity. The fixing of defects is not adding any additional value to the business. The value was added already through the feature. This defect which we have given with the feature, it has reduced this feature value. So we are just giving back what we promised on the first place. So it's not adding any new additional value to the business. So it means that we are spending the time on doing something which is of no value. That's bad. Defects cause rework. So we are again and again working on the same things, right? And late discovery which is happening in QA, in UAT, or even in production, it increases incredibly the cost for fixing it. And we see that at the moment when the code is touching the production, then fixing anything is huge cost. Not only on the IT side, it's a cost. It has happened also that because of the bug in software, we had to reproduce a weak worth of production just because a bug of software was there. And that's really bad. It costs really a lot of money. So it's not just IT cost which is there, it's also the business cost which is there. This kind of chart everybody has seen. I was not sure about the copyrights. In Europe you have to be very careful about that, so I draw myself. Nobody can accuse me in using something but it's not allowed. So, right. Then I thought and thought, no, but let's assume that it's possible to do the zero defects. What would it change? It would change a lot of things. But let me think, okay. The few basic principles. I was speaking with the production guys, production guys have it all the time, right? Production is normally running with the lean principles. You know, you learn from the defects and you improve until six sigma, zero defects and so on. But on software it's not so straightforward, but at least I thought, okay. Let me at least think how to apply the principles. So removing the obstacles between the teams and users. That's like this whole BA thing, okay? Not so popular with that. Removing the BAs to just bring together the team and the users. We build that or we change the processes and we adopt our tools so that we can support this, this newer way of working, whatever it will be. I was not yet sure what exactly we need for that, right? Moving discovery of defects to as early stages possible at the moment when it's still cheap to fix. The cheaper the fix, the better it is, right? Automation of everything. As we are running under the compliance, we have to still do the documentation. We have to still do the validation, is that? So if there is an action which is not adding value and which only is costing the time, so automate it. And then we had also the plan B. We could also analyze the gene expressions and figure out which gene expression is responsible for producing the low-quality code and then we could use the CRISPR and then for repairing the DNA of our developers. But that was only plan B and good we didn't have to do it. But it's possible. So we apply these few principles. Very few principles were there, right? What happened to our defect density? It's until December, I think, or January. Every of the small block is three-week sprint. So we did hit, at the beginning, a little bit of struggle with the old legacy code. There is still a lot of bugs in the legacy code, so it's not that easy. But as you saw, after some fluctuation, we are nicely zero. So there are no more bugs. What does that mean? No more bugs. That means that we could spend the time on doing something, right? What production says about that? No more bugs. So theoretically, we could even skip the validation process. As you guys are anyway giving us only the bug-free software, we just lose our time in checking something what is anyway working. Okay, it's not allowed. They have to still do the validation. But it's very easy. Then they are ready to do it also anytime. So, okay, but the highest quality, zero defects, it costs a lot, right? Because in the past, we have to be really fast. Let's skip a few of these quality checks. Let's be fast. The quality we can fix later, right? And then if we have to give really zero defects, let's postpone our release. Let's do more of the validation so that we can give zero defects. So that was the kind of thinking. So the velocity should be also around zero, right? We spend all the time on fixing only. Fixing, validating, checking, verifying. So this is our velocity. This is one team. Again, each bar is three weeks long. It's three weeks sprint. Interestingly, or as production guys will say, of course, we told you, right? The productivity is going up. I still think there is a lot of potential of going up even more exponentially. Still, if you look back what we were doing, we were mostly working on defects, a little bit velocity fluctuations. Sometimes we were even recording the defects under velocity so that you can have some planning, right? Still. Now, the velocity is up there, and it's not the limit. And the zero defects, the same team size. It's not like we added 100 more people and said, okay, now we do the great quality and the velocity. It's the same team. Same team, but no defects and a lot of velocity. So this is an acceptable cost of quality, the sweet spot in which the fixing of defects is more expensive than delivering additional functionality. My sweet spot is up there. It's a place where we don't have defects so we can spend all the time on only producing additional value. So how we did it? As I mentioned, few of the problems around it, also solution was obvious. So release cycle reduction, release often, release more. This, everybody knows, right? But we just don't apply it at the moment when you have to do it. Then there are always some obstacles around that. I could say, okay, you need a huge buy-in from the business and all of that. At the end, it comes back to the same, release often, release more. This is what we did, right? Then what else we did? Riffing of QA role. So instead of spending the time of QA for verifying the functionality which had to be error-free in the first place, the QA is spending time verifying something that the developer has to deliver. Not really the point. So the developer was made responsible for the QA also. So the developer had to do the testing also. The testing of his newly added functionality. Okay, there was also the peer testing, peer review, so that it's the four eyes principle, still, right? And all of that. But the QA role was now more on the automation side, security testing, load and performance testing, exploratory testing. There is a lot of work still outstanding for QA. I'm not saying no QA thing. I know there is also this thinking around, but I still think the QA role is very valuable if it's used in the right way. Ownership, the developer has to own his code, what he's writing. It cannot be that he just writes something, the code, and then throws over the fence to the QA, and then, okay, it's not my problem anymore. The developer is responsible end-to-end. That's why I want that also the developer experiences the pain of the users. If you remove the B.A. from in between, and if you remove the QA from in between the user and the developer, he will experience also the pain, which the users are experiencing, working with this piece of functionality which the developer has delivered. And the developers, they are not wanting to do the good quality, right? They are very keen to give the great quality, and I just allow them to do it. I don't stand in the way for them. So, of course, the other basic principles like, you should not assume that the user will do in the right sequence, right way, that the systems will be up, that the services will be running, and all of that. That's all we know, right? All of that, that you should build for the stability. You should not just build in the functionality and then hope nothing happens. The user doesn't click that other button. The peer review and testing, which I noticed, which I mentioned before also, it's not just about ensuring that this code is working. As for me, it's also about the pride. If you show the other person what you have done, and you say, okay, this is a code which I have done, and that other person is another developer, so if I will say, and you'll say, okay, but what is that? What did you do? Why did you wrote it in such a way that it will break immediately? Come on. It's not something what I as a developer would do, right? It's your colleague. I should have a little bit pride. And also, this helps really sharing also the knowledge and understanding about the software which we are developing. And then something really crazy stops the line. That's one of the basic lean principles in production. At the moment when you have a defect, it stops the line. It stops the line and figures out what went wrong. Okay, it's very expensive, right? Imagine the full production line is stopped just because one small defect is there found. But if you don't do it, then the defect is not an exception anymore. And if the defect is not an exception, then you quickly end up in exactly the same situation as we ended as the first place. So we stop the line. It helps us also learn from defects. How does it look like? Actually, it's okay, it's very few. You have to stop the line. This is how it looks like. We did it. So not because of copyrights, but just because we wanted to do something quickly and not wait for some special instrument to do it for us. So we did something like that. So normally there is a green light. Goalings is the name of one project. So it's normally a green light. And whoever discovers a defect, whoever sees something is going wrong, goes there and there is some button here which you can press. And then the light will become red and the signal will come, acoustic signal. And what happens? The team stops working. The team stops working and comes there, the full team, not only the guy who discovered somebody from QA as a help or other way around, it's really the full team who has to come there. They will come, they will discuss what happened, what went wrong, what we can learn from that. The defect is a learning opportunity. So you stop the full work, you figure out what went wrong, and you can discuss also how you will fix it, of course. All the experts are there, so you can discuss how to fix that. This is one of the powerful tools which we built. And we didn't change the design much after that also. It still looks pretty much the same. Not extremely cool and nice, but it does its job. It stops the line. So then, of course, we do the continuous code monitoring. That's something what we added, not as long time ago, so you can still see there are also, a lot of issues are ongoing, there are duplicated items, and code is not well documented, maintainability is not yet as high as it should be. It's SonarCube, by the way. But the basic idea is that you have to invest. You have to invest in the maintainability of your code. If you don't invest, your code will naturally evolve into a more haeotical state. That's the basic physics principle, by the way. Everything is changing into more haeotical state than before unless you add some energy to it. Only then you can increase the order instead of chaos. So the quality gate we call it, and this is also where all our code is going through it. Still, as I mentioned before, regulation, so we have to do also the documentation. Without documentation you cannot do anything. Then there are a few principles which we try to follow. I don't say that we are ideal in that, but this is what we try to do, and we try more and more of that. Documentation should be generated instead of writing, and what I mean is that at the end, a lot of the tools are out there which can generate your documentation from the test cases, from the test steps, from the acceptance criteria, from the code comments. No regulation says that you have to write all your documentation sitting at the keyboard and typing, actually, something, and then signing something physically. That's not what regulations say. They require documentation. It has to be clearly documented how it works. And there is this executable documentation. In the most simple case, it's acceptance criteria. Then there is also the test automation which comes on top. That's the documentation. It documents exactly how your code is working. That's the best documentation. Anytime you can ensure that your code is exactly working as described in this document, which is the test cases for automation. That's the exact documentation. Late documentation is not like we are being late in preparing the documentation at the moment when already auditors are there. No. What I mean is that we don't prepare documentation before we deliver the functionality, basically. The more you wait with that, the more precise you will be and the less time you will spend. Right? Otherwise you would be describing and documenting something which might never come. Electronic cover paper. This is what we are trying now to do. Ideally, I would like that the application itself is a documentation that for any feature you can anytime produce the proof that this is the functionality how it is and this is a documentation for that and that the people in the lab would even use our application for validation process also. They would come just at the screen at the machine at some robot and just check working, working, working, working and then with the fingerprint or with RFID chip, then approve. Yes, I have validated and that's it. And then anytime an auditor comes, then we can produce as much documentation as they want. How much we want? 3,000 pages? 10,000? Whatever. We can produce. Then we can print even out if they are so keen on printed documentation but otherwise it's not our business. We are not into documentation business. But still, I cannot say that it just diminishes completely. Some documentation still will exist. Sorry for that. I have no better use for that. There will be always a need for some documentation, even some written signature with blood or something so that you can really verify that you take the responsibility for this patient who will die if you have done something wrong. And normally it's at the end at least the general manager has to sign because he will go into the prison if it will not work. So... And then the last step for me was always follow the plan. Okay, we are all agile, so we do the sprint and then we do the re-plan and then we re-prioritize the backlog and think everything is good. At the end, you have to... If we are building up the new lab or if we acquire another company, you cannot say, okay, yeah, we will be working on some functionality based on the priority, whatever the product owner will decide, and then at some moment in time because we don't commit also, we will deliver something. Of course, the other side of it is, oh, okay, let's just write down everything what is required, right, and then we will estimate and then using very nice and advanced planning techniques with the previous story points and with machine learning, then we can somehow estimate better, right? And then we know that we will hit the line. This is our strategic roadmap. You can't really see, and even in the slide handout, you will not see because it's a secret. No, it's not. Actually, it's just a low resolution, so you can see even a few things there. But it's nothing interesting. It's on a very strategic level there that we are working, for example, one bar is one system which we want to do. So one bar, one system, no details. As it's far in the future, I have no idea what I have to do there. Sorry, no idea. I have to work in 2020 on the new system for microarray business. Okay, I will work on that. So how much money I have? Okay, I have money for this much people for one year. Okay, fine. That's enough for strategic roadmap, right? It's budgeting, it's roadmap. Enough. If we do more details, what is that waterfall? So we don't want to do waterfall. So what do we do? Then when the time comes, when we should start with one of these systems, which is in the far future, then we do the product roadmap. Mostly the business people do it. The production guys, or if it's the production system, they would identify and write down really the independent blocks which can be deployed independently. That's very critical. It can be deployed independently. So it's a minimum functionality which is usable still for the lab. It's not just a set of functionality which from IT perspective makes sense somehow. It's the minimum set of functionality which is usable in production. So this is like a zoom in. So a zoom in when the time comes, not before, which is very important. The commitment has to still be delayed. So we delay the commitment, we say, okay, now the time has come, now we say. Still, okay, all these colorful lines are program increments. Almost three months cycle on top, which say, okay, in this program increment, we have to work on this piece of functionality, this block, we have to do now. Now we have to understand what is that block doing. So we do the breakdown and we do now the sprint planning for the next sprint only. So we don't do any planning for the future. We don't care. How do we still ensure that it's on time? Right, because the acquisitions and the new lab setups and new machines come, how do we ensure that it's still on time? And again, as copyright thing in Europe, so I draw something. So what we do, we identify the core functionality. The core functionality comes into the first sprint. If two sprints required, I'm fine with that, whatever. If three sprints required, I'm fine with that as long as it's the core functionality. And when we work on the core functionality, what is the deal is that if somebody is working longer on core functionality and other person or team is finished with their core functionality, they don't start with the next one. They go and help the other team or other person. So that at the end of the program increment, we have the functionality which is acceptable. Okay, it can be still very core and things, but it's acceptable. Then if we have the time left, then we work on important functionality. And if we are even more lucky that we have so incredible amount of time, then we just maximize the value until the end of the program increment. And we are always done. We are always on time, and we deliver the maximum value possible. So that's how we do it. So, questions? I'll give you the mic, sorry. Hello. I feel when we try to give importance to quality, which is very important, our competitors can catch up and it could be a matter of not able to take that position again itself. But did that kind of situation happen or how did you manage with the kind of strict policies that you have? You see the strict policies are for making us fast. If we think that what we have to do for beating the customer is this functionality, then we will go and deliver the core. Then we will deploy the core in production. We will start using already this functionality. We will get already the value so that we are as fast as the startups. We do the minimum, then we get the feedback and the functionality which we thought is important is not important anymore in the meantime. So the team was not a distributed team? It is. It is still. So how was the time zone managed and honoured? We are pretty lucky. With Germany, it's three and a half or four and a half hours difference. The people here start late. They start when in Germany, the people just reach the workplace and they end when the people in Germany also go home. Thank you. It's good for us. Just one small question. On the graph where the defects have gone down and velocity is going up, are those numbers that have gone down to zero, is that only post-production defects? No, it's QA. There is not a single defect in QA. That's defect density. So it's everything that is found after the development. So the QA is not finding any defect. Only or QA plus UAT plus post-production? All. It doesn't matter for me. Again, defect is defect. Okay, thank you. Just wanted to understand on the QA role redefining, how exactly and what were the steps taken to redefine the QA role? The simple answer is that I want the QA to deliver more value. Retesting the functionality which the developer has tested already is kind of useless if the developer has delivered a good quality, right? So I want that QA is spending the time on value-added things. Now the QA has taken a role for helping us achieve the GAM5 full compliance. So the QA is helping now the production people to ensure that our software is always validated, which was previously only the production headache. Now the QA has taken that responsibility. So they are spending their time on more valuable tasks. Can we go to that slide? Which one? Yeah. One more with respect to stop the line. When you say stop the line, what exactly you mean there? Stop the line. I mean stop the line. I mean at the moment when we discover defect, whatever is that in QA, UAT, SIT, production, somebody comes and presses a button and then it becomes red and everybody drops the work and goes there and checks what's the issue. And then they discuss what exactly happened and how to go about it. And it's not about the regular sprint. If there is something critical coming out. Any time when something happens, we stop immediately the work. If you are more interested about the stop the line, this guy there is stopping the line no more every day, but initially he was stopping every day. He's sitting there. Any more questions? You spoke about defect management and all. Like how did you make this happen? Like the strategies and all. So what do you think, what is the differentiated strategy which your company is having compared to your competitors which keeps you leading in the market? Because the defect management strategies which you have shown here, almost most of the company would be following the same kind of a strategies. So what is the differentiating aspect which you feel it had it, which is helping you to having a lower defect rate? I think it's a courage. It's a courage really to change the thing on how we work. Like stop the line. It's how you will stop the work what you are doing, right? Just for learning about the defect which you encountered. It's crazy. You have to have the courage for not accepting any more the previous state. Thank you.