 Good. Shall I start? Okay. Hi everyone, can you hear me? Is the mic good? All right. Good evening everyone and it's great to see such a crowd coming and I'm really honoured to be invited by my dear friend Sergio to talk about a topic that is very dear to my heart and I hope this evening will be very good for you to have some good takeaways to implement at your organisation wherever you work because I think that is the current way of how you actually have to deliver software and to be able to produce the best product. My name is Flavio Monigatti. I work for Credit Suisse Singapore. I mean Singapore since about one and a half years, a bit more than one and a half years before that I worked in London and before that in Zurich and also with Credit Suisse in IT obviously and before that I did a postdoctoral research studies in bioinformatics and biology so if anything is wrong from a technical perspective please keep in mind I'm a biologist by training. So from an agenda I would like to first talk about a bit of inspirational material that I would like you to read if you haven't read it yet. It's really important material and I think you will get a lot out of it if you go through it. The second point is I'm going to talk about interview questions and I'm going to tell you the reason very soon why I'm talking about that all good and then I'm going to talk about cars, birds, statistics and switches and you might find now that this has not much to do with lean development or continuous delivery but hopefully you will realize then that it has everything to do with it and it's a great analogy that will help you understand the concepts hopefully better. And last but not least then I'm going to talk about continuous delivery and the experiences that I have made companies and work experience and what it means to me and at the end of this session then we can go back to the interview answers and hopefully get something out of it and then last but not least if you have any questions let's go through those. If you have any questions during the talk interrupt me and if I can answer that I will answer that. If not hopefully we will pause until the end and then by the time we have forgotten about it and then I don't have to answer that. So does it work? Yes, very good. So the first books and there are many books on this topic but I think this is really one of the most inspirational books about the topic is Lean Enterprise by Chess Humble, John Molesky and Barry O'Reilly. It really gives a very, very good introduction into the topics and explains how big enterprises by applying Lean methodologies can actually deliver high quality products in time and at the same time are able to innovate. Very recent. I don't know how old it is but it is relatively recent. It has a lot of anecdotes and I'm going to talk a bit about those anecdotes and I think they're really interesting and it's a good read. The next book is a classic probably most of you know it already. I just brought it up because really I think it's such a good read and a lot of the examples that are given in the book are actually real life examples. I can relate to them because it wasn't as bad in my past experiences described in the book but obviously some of the examples are really real life examples and it's a well-written story. It's very interesting so if you haven't read it I can recommend it. It's really nice. So when Sergio asked me to do a presentation on continuous delivery I already had kind of ideas in mind what I'm going to talk about and then one morning I stumbled upon this article here that from Eogan Nolan talks about the leadership interview questions that Google, Facebook and all these tech companies ask to understand whether any the candidates that they interview whether they are leadership material or not and I went through the questions and thought that okay this is really interesting because by understanding the development principles continuous delivery I can actually answer those questions and that is why I would like to actually go through these questions with you, talk about lean development and at the end we can answer the interview questions and hopefully you will get the next interview with Google or Facebook or whoever you want to apply to and when you ask these questions you have the perfect answer for it. So the first question is how do you deploy technology against the business strategy? Think about it the answer is not waterfall how do you address the dynamic nature of our priorities which can be constantly changed or modified explain your decision making process when it comes to major technology investment and the last one is how do you stay current in terms of knowledge and skills in the face of a never changing technology landscape so these are the top four he mentions the top five interview questions I'm not going to answer them now but please keep them in mind for the last part of the session where we answer those questions then so why lean development I believe I'm a strong believer by following lean principles you will come to a realization that this is the only way you will be able to deliver high quality software in time to your clients that satisfies the client's needs and at the same time you will be able to innovate so this is great stuff what tool can I buy to actually make this happen for me and I have to disappoint you unfortunately it's not about the tool there is no tool that you can buy to make this happen and the hard truth is it's a cultural change that you need to go through if you are there or you need to teach your colleagues to go through and your organization and everyone so it's not about the tool it's a cultural change that needs to happen and I'm going to talk about what this culture means and you may have experienced similar traits already in your organization maybe not I have certainly so I would like to talk about cars does anyone know what this is what this signifies have you ever seen this do you know what this thing here is it's the Andon court it says here so yeah a lame joke so basically this is a Toyota car manufacturer and the Andon court is actually quite an ingenious device what happens here is that whenever an employee here sees an issue with one of the cars that is being produced he or she can pull the Andon court and the whole pipeline or the factory or the current car making process comes to a halt and actually the manager comes and identifies the issue is together with the employee and they fix the issue and until it is fixed it stops it doesn't continue and only when it's fixed it continues and that is very important and for several reasons which I'm also going to allude to later onwards but for now as well as then once the issue is fixed there is actually the root cause is identified and it is made sure by continuously improving the process that this never ever happens again and that is why Toyota is able to produce great cars high quality cars because they understand that every small issue is an improvement and they have this concept of Cata which is a continuous improvement and there are two reasons or multiple reasons why I'm telling you this so the first reason is that if you see an issue with the presentation you can pull the court and Sergio will come and save the day for us hopefully and the second reason is that he acknowledges in a delivery pipeline with a car manufacturing pipeline and I will tell you later about why it is important that if there is an issue that you stop and fix the issue before you continue because if you don't you can imagine that actually you produce bad quality builds that go into production good if you're thinking about cars it's time to talk about birds and it's not the movie it's the black swan theory who is familiar with the black swan theory Sergio so the black swan theory was a theory described by Nassim Nikolas Talib and what he actually describes or defines as a black swan event is probably a rare event with an incredible high impact and they are so rare these events with a very low probability of occurring that they are very hard to predict but obviously you want to be able to predict them because they have such a high positive or negative impact that you could be the master of the universe if you were able to predict them but unfortunately nobody can predict them and his theory has a lot of followers in banking finance but also in science think about the discovery of DNA is such a black swan event or market crashes that nobody can really predict are black swan events and obviously you want to try to avoid them if they have a negative impact and if they have a positive impact you want to actually try to well try to make it happen to you and it's all about statistics produce software and deliver software and if you are trying to be innovative you want to make it more probable to actually hit the check pot and the check pot being you have an application that users use and the more user the application use the better and what is depicted here is that you go through several iterations where you produce new features and you have to go through a lot of iterations to production that is so innovative and so great that everybody loves it and you see a spike in usage of the application now how do you actually come up with such a feature you don't know right you don't know otherwise if you would know you would actually develop it in iteration one and don't care about anything else but through many iterations of producing software so the first iteration you have five users second iteration three users because you introduce the bug but then you go on you go on and the faster you are the more likely it is actually that you hit the check pot so it's a simple probability measure that you can actually make it more likely to hit the check pot by iterating faster so meaning that if you apply lean principles and build high quality software more often introduce it to the client you are actually able to increase the likelihood of hitting the check pot so and obviously what you can then think about is okay I can even take a riskier approach and the riskier approach is I do something with feature toggles where I deliver unfinished products but still high quality features into production and only enable them once the end to end feature is fully functional and you can do that with feature toggles obviously feature toggles is not easy to implement and it requires a lot of front to back alignment to make that happen even better if you can actually do it based on trunk based development then you do true continuous integration and we can talk about this a bit later what exactly this means and once you understand these principles you will be able to continuously deliver features into production that are actually not even completely the complete feature scope but still fully functional so that you can actually already expose them to the user analyze the update and understand whether the feature is actually successful or not so it's all about delivering value to the customer understand whether the customer likes the feature and if not what you do is you are actually you further develop it and if you further develop it you might actually see an increase in usage adoption and if the feature is not liked by the customer you take a decision either to improve it or you are actually abandoning it there's nothing worth working on a feature that nobody likes it's not only bad for the company itself because they waste money I'm motivated if I work on a feature that people like it's good so it's very important to actually analyze the usage of any feature that you deploy into production if not you have no idea whether it's really a waste of money so optimize optimize the analysis of features that are introduced so you can get an understanding of whether you are doing useful work or not if you're not doing useful work do useful work and now I'm going to talk a bit about how you can actually achieve that and the only way you can really achieve delivering features fast into production with too high quality is actually by applying continuous delivery methods or principles and you have to set up a delivery pipeline essentially it's relatively simple if you take the analogy from the car manufacturer it goes through several stages and only once the last stage release into production has been achieved or met you release your software automatically into production obviously this is an ongoing product life cycle we're talking about products not just software anymore very important is obviously that you honor the test pyramid here what does that mean basically you have a level of unit testing you have a level of integration testing you do performance testing all these you need to be sure that whatever is genetically done gives you very fast feedback this is the most important fact here fail fast because if you fail fast you can fix it if you fail in production it takes a lot of pain and a lot of overtime hours to fix it you get yelled at it's not good so you want to fix it when it happens and this is the very early stage actually you can even prevent that before you commit your code to your repository because you have unit tests locally running and the test pyramid says nothing else then have a lot of unit tests that run very very fast so you can actually make sure that your build is good then you have a bit more integration tests and last but not least you have a few end to end integration tests and hopefully you don't have any manual tests but there are still sometimes still manual testing is required and we can debate about this I would like to hear your opinion on this what is very important is all this of course is automated and no manual intervention should be necessary but again remember the undone code at each stage you want to be able to break or succeed and understand whether your build has the quality that is needed to go into production so very important visualize the progress make it visible to the developers to your managers even or to change management but my build is currently here it failed to deploy so why am I even going to release it into production yes ok it happens right but you have the chance then to actually act at each stage and implement quality gates right coverage is not 70% I'm stopping until it is 70% ok you can then of course arc and we can have a debate at the end of the talk whether KPI driven development is the right thing but the right thing to do is all good the right thing to do is that you are confident that your do I need to do anything am I too late talking too much at any stage you want to have confidence that the build artifact that you produce is actually of high quality it's all about confidence really and you want to be confident that whatever you deploy into production is actually up to the standards that you want to have obviously at each point in time you can reject or retain release candidates treat every build as a potential release candidate because if everything passes and all the tests are good you might actually want to deploy this into production so don't create release candidates only at the end when everything is good treat every build as a potential release candidate and once you have mastered all these you can then think about ok why not build my build environment every time I deploy and then if you are fancy why not build your environment where I deploy my code every time I can before I deploy and you can spin this further and further and there is no limit of how far you can go and how fast you can go it's all about speed fail fast do write unit tests I cannot emphasize that enough unit tests are your friend they are your friend because five months down the line you have to touch the same code you don't have a unit test you have no idea of whether it's good or not that you make the change so it's it's really the literature that is out there is out there for a reason and we just have to do that and I know from a past experience that not everyone does it and not everyone understands why you need to do it it's not a pain it's not a tick in the box that you do it's actually helping you to be faster and more relevant so for this part I would like to talk about some experiences of mine that that I had in my previous companies and past experience where a lot of development was done on relational database management system I know that I don't know how many of you have to still work with relational databases but I do a lot and we don't have those technology technologies because we do persist a lot of data that needs to be that needs to be persistently and atomically stored and therefore we still rely on a lot of relational database management systems but what a lot of times what I experience is that continuous integration and continuous delivery with relational database management system is not done because these systems are 20 years old, 30 years old and maybe not 30 years old but 20 years old and the people that were working with them they were used to a certain process and that process has been actually given past on to other developers over time and the process has not evolved much but still you ask yourself then okay how can I do continuous integration and continuous delivery with relational database management system and it is possible so what do you have to do in order to make that happen? Okay first of all you have to explain why you want to do this because the developer doesn't believe that actually this is better or faster because the developer has done it for five years and maybe once or twice something has happened but most of the time it's all good and it's great how they do it manual deployments we believe in manual deployment the second once you have mastered the first stage why you do this you have to actually check the scripts how they are source controlled and it's actually said but a lot of developers that I have had the pleasure to work with didn't really understand the beauty of source controlling and revision controlling and comparison of previous versions so and with database scripts very often it was not properly done you could also have news sharepoint to do your source controlling for database scripts so properly source controlled any scripts that is ever been deployed into a database so treat it as infrastructure as code if you will then once you have mastered this you have to build tooling around deployments automation and actually well keeping track of your deployments into any database and there are you can build the tools yourself I mean it's not that difficult all you need is a JDBC connection to a database and run the script there are good tools out there to do that and we can talk about tools that I've used in the past that are working very well I'm not mentioning any tools because remember it's not about the tool then what you have to make sure is that you make your deployments repeatable and important so you can actually deploy the same script over and over again with the same effect this is very important because you want to keep track of the changes that you have made into your database ideally you keep track of the database itself what you have deployed and not obviously the last point the number 5 is you need to separate environment properties from database environment properties from your source code in order to make it deployable environment with the same process over and over again so you use the same process all you change is your environment configuration to which database you deploy very important the next point is somewhat difficult and I haven't seen it done very often and I haven't seen it done greatly so I think this is still a gray area in unit testing you can write database unit tests if you do it you master it I think it's very important because ultimately what you want to want is that I don't have to write unit tests because actually I have someone to write integration tests once the Java code is deployed or your web service is deployed that calls the database objects this is a bad excuse you have too many problems you have to write database unit tests but I understand this is not a trivial task because there aren't that many great frameworks out there that do that but there are then last one of these you integrate with the CI tool of choice to make it runnable repeatable deploy every database change once you have a source code commit you deploy it first to a dev environment that is you and not directly to a user acceptance test environment or a system integration test environment I've seen it all it's important then to actually show a track of successful deployments in any environment with database codes you can deploy automatically to dev you have confidence that it works you can deploy to the next stage you have confidence that it works but still a lot of people actually or a level developer directly deploy into UAT or SIT or even worse what they do is they send their script via email to the environment management team where they execute it then from so all of that needs to stop you need to integrate it and automatically deploy it now last but not least once you have done all this obviously somebody needs to write integration test because you want to make sure that your database code objects work together with whatever web service or application code and I know you might say that okay there are object relational tools out there that actually solves this problem for you but you have to realize that not all of the legacy applications let me call it like that or vendor applications are actually suited for this type of application so there is still a lot of database objects to be written and a lot of time actually it's a hard debate between database developers and Java developers who writes the more performant and faster database access code and you would be surprised that even in 2016 there are these kind of debates going on and last but not least what you can then once you have mastered this you can think about okay why not combine this with a data virtualization technology because what I can think then is every time I commit a change to my environment or to my source control repository I refresh my database or my virtual database from a productive copy and apply my changes so simulating every time you do a code change you simulate a production deployment therefore you have very high confidence that whatever you produce is actually working and working in production and once you have done this then there are still people out there who actually don't get it and so you have to explain it again it's continuous integration that's what it is and by the way I mentioned that is not about the tool it's really not about the tool and please believe me okay so that is actually all of it that I wanted to tell you I could go on and on and maybe we can actually talk in the question and answer sessions about this but hopefully now we can actually go through the interview questions and get an understanding of actually why I think lean development is the answer to a lot of these questions so how do you deploy technology against a business strategy by applying lean principles how good can it be right it's lean faster, better, higher quality and innovative at the same time so how do you address the dynamic nature of your priorities which can be constantly changed or modified it's not waterfall it's you apply lean principles and you will be able to actually address these very issues number three explain your decision making process when it comes to major technology investments the answer is not lean the answer is you do a POC with the technology by applying lean principles you don't want to spend six months evaluating a product and then after six months you realize okay this was not the right one you want to be fast and nimble and four how do you stay current in terms of knowledge and skills in the face of a never changing technology landscape by joining these meetup sessions and hopefully you could actually tell you a bit about what I'm passionate about what I think is really important in nowadays ever changing digital world and hopefully you take away some key points that I wanted to make and it was useful to you so we have now time a bit for question and answers and my question to you is when do you adopt continuous delivery and lean development if you haven't already who is who of you is doing lean development and delivery continuous delivery very good good who is doing waterfall search you okay are there any questions was it useful to hear or are you already doing all of this you knew all of this already so the thing is there are I mean the bank is really a big IT department it's really big and there are a lot of teams that are actually working on legacy applications where only maintenance is going on and there to introduce this kind of content is more difficult and more challenging but that doesn't mean that the concept of continuous integration would not apply right maybe from a continuous delivery perspective with our and we have to say that we have a lot of monolithic designs where let's say interdependencies between components exist and we are trying or part of my role in the bank is now to actually define strategies of how we can actually move transition away from monolithic design to a more distributed designs architecture so that we are actually freeing ourselves from these dependencies so that we can deploy components independently and apply these methodologies but it is a long way to go because traditionally these systems have been built in a way that it is more difficult to apply these principles but it is still possible right so continuous integration everybody can write test cases everybody can integrate with a CI tool everybody can actually automate and operationalize their components that is not an excuse but it is more difficult I would admit to that but we are very determined to make that happen How did you manage to change the culture not the development side but the design form and the step size to change the way to view changes in these I have an issue it is not the IT guys who are against the decision-making it is more the business people who are more waterproof I give you 5% of IT departments and you will meet that implications and we will enlighten you on that So this is actually something that is still going on I mean it requires quite a lot of interaction and also not convincing but the problem is the processes that have been established they have been there since 20 years and budgeting process this is pure waterfall you have to ask for money to deliver features that you don't know whether they are actually good or bad you have to deliver that and what we have done is to approach this actually we had many many sessions with the business to actually address these challenges and we have not gone from 0 to 100% but we have managed to actually step by step change the perception and the processes of how we want to deliver business value to them because they realized it as well oh I get things the HR is a big driver to that but the HR is not good enough because you deliver than waterfall HR you just deliver in 3 months chunks and yes you have a 2 weeks brain cycle but it is still better than actually pure waterfall because every 2 weeks you can see a demo of your product and you see more or less what is going on but now we have gone from a 3 months release cycle down to a monthly release cycle and hopefully we will be even even faster but it is a long journey and it is difficult we vendors how do you change vendor's waterfall contracts because for current contracts we vendors are very waterfall did you really change contracts no this is a big discussion that we need to have with our vendors because they have to adopt as well but on the other hand my view on that is that you have to try to isolate yourself from those changes and not fall into the trap that I will only deploy my changes if the vendor is ready you deploy your changes as soon as you are ready and once the vendor comes in you are actually already ready and you focus on other things but this is still a problem yes in the process of continuous delivery and continuous integration you cite a lot of tests so who write those tests to the developers and then they put the code in a version so who gets the code, goes pretty pipeline, checks if the tests are good enough or not good enough, how does the process work so at the moment we come it is an organization that has grown organically and it was very water fallishly grown we had development teams and we have QA teams and we have environment management teams and all these teams that have to actually produce software together that works which is non-working but we started off let's say as very traditional and what happens over time is that the boundaries between the teams are actually moving away so we don't have QA engineers that do only QA we don't have developers that only do development and I think this is then the very first step of teams realizing that they are working on a product rather than on I only do development so they go through the whole product life cycle and by changing that realization, oh I can write an integration test there, why don't we pair and do it together and I think we are not there yet where we want to be right but I think we are on the right step that the teams are actually or the teams are self organized and they can actually tackle a feature front to back rather than we have the team that only looks at this component and this team looks only at this component we have front to back teams that are empowered and able to actually deliver everything integration test, end to end integration test and so forth I think this is very important that you go away from thinking of kind of teams that only or developers that only do one thing a developer should be able to do everything and so we try to apply the Spotify model where we have squads that do certain things front to back rather than only one thing and because then you are actually again going into the dependency, you don't resolve the dependency issue, I'm always saying this and this is maybe very corny but I think it's much harder to resolve the dependency issue than actually going or isolating yourself from that dependency issue so the microservice approach is very much helping in that respect so that you don't create dependencies, you actually isolate yourself from dependencies actually I will not stop, I think we can move the conversation to the break area and we'll have like this I don't need to prepare for the next presentation Thank you very much