 So I'm going to talk about the holistic development and operations environments, and it's not a technical talk about holistic devops, the devops is there in the core, but it's kind of starting to think about the devops and how it's kind of holistic approach of things and then working upwards from there and bringing new things, everything that's surrounding devops and surrounding the software development and just grew up from there, sorry. Minä nimi Janne Kopponen, I work as IT operations manager in Wunder based on Helsinki and as an operations manager is great position B because there you can help all our different people working on different disciplines. So it's not just technical stuff, but also helping people and enabling people to do their job, so helping people to help our customers and empowering that work. So I say that it's not about devops but development and operations in general, so let's go through those terms because it's kind of nice that they are not so simple and they don't have just one meaning. So as a holistic, it's a practice that you don't focus on the details but you see the whole and you see the value, there is a lot of value added to the parts, it's not just the sum of the parts. As a developer, it's not just a code, there is self development, there is the team development, company development, community development, a lot of things that can be put under the development term. Same goes with the operations, not just susops, there is the business management and whatever and environments, not just servers, local environments, but actually the people you work with, the community you live in, your family, a triple community, the whole society. So this all connects together, comes together, works together and there is a lot of added value in between those different places. So what are the benefits of kind of having that kind of thinking that you don't focus on the details but you see the whole picture. So then you can see a lot of improvement possibilities, not only what you do but how you can actually help others, understand what you do, how others can benefit from what you do and making things easier for everybody. And about the improvements, there is like, you can focus on small things, but when you put them together, you get great success. So in 2010, Brits were kind of, we haven't won any Tour de France ever and we need to change this. And this guy, Dave Pressford, was appointed as the chief coach of the British cycling team. And he came with this idea that if they focus on improving everything that there is related to the cycling and it wasn't just about better bikes, better training schedules, but it also includes like a bit of better pillows for the cyclist. So they get a bit better night sleep and they are well rested, better drinking bottles, better everything. So small improvements. And he promised that if they follow this in five years, they will have a British Tour de France winner. Well actually he was wrong, it only took three years with this matter. So these small things, you improve everywhere when you think the whole all put together can really improve the performance and everything. So just improving something by one person. One person is so small thing that it doesn't take much to improve. And of course you can take that it doesn't matter that much that it's not worth doing. But of course one person is actually quite a huge amount if you factor in all the improvements. You do a lot of those one person improvements here and there and different kinds of different parts of the system. So you get nice interesting that you are investing. So over one year if you keep up improving one person every day, you end up with 37 times the original value. So it's huge. It's actually trying to do that one person per day is impossible. Even if it sounds like it's so small. So even one person per week you end up with 67% increase over the year. So small streams, big river. Of course with the small changes it's hard to see the change because it's small, it accumulates all over time. So there needs to be some way of measuring that change. So it's important to keep an eye what's happening, looking back where we were, where are we heading and having some actual data. So you know that you are actually doing the correct thing. And by that it's important to see the feedback what's happening, what is the outcome of it. And getting those measurements, feedback, collecting all the things you can and making decisions based on actual facts. And of course not always everything comes together, they don't work. But with those small improvements it's also easy to go back. Sometimes the change is not an improvement. But with small changes it's easy to come back. Like it was nice to hear Andreas talk about the triple UX improvements that we need some new modern JavaScript based framework for the UX, for the admin side. And he said that we are not going to do it like trust the old one and replace with the new one. But we start with some small part of it, we test it and see how it goes and so on. And then if it works it can be extended to cover more of the admin side of the triple. And Toyota is really good at it. They have this kites and philosophy of constant improvement. And they have a really good system of collecting all the improvement ideas the employers have. And if you think that one million improvements they are quite small because there are so many. But what's more astonishing is that 90% of those improvement ideas get implemented. So if you have the system in place you can collect ideas, you can actually implement them and of course then afterwards measure them. Well Toyota is still one of the leading auto manufacturers in the world. So it takes a lot of work. But it's small, it's worth doing and it comes in and it starts rolling. You do small improvements and it's not only for that but then it's multiplying. You get easier like improving the process of actually improving. You get easier improvements, easier ideas of missions and everything like that. So instead of like setting some goal that we need to improve 10% this year, you just keep improving indefinitely and you will get quite far with that. And there's also a problem with if you set the goal you may or may not reach it, but when you reach it then you are happy that okay we did it, but what next? Then you kind of settle to that level and you know. So there is many things where you can improve a lot of different areas. But the idea is that with holistic ideas that you don't improve in your own silo, you tear down walls and work together with other people, other departments. Like DevOps is one of the disciplines that brings together developers and the operations people. So it's good like working together instead of there might be that it's not the correct way of doing like there's the developers and then there's the operations and you put the DevOps like another silo between them. And then there's like instead of one communication interface, you have two and things get harder to pass forward. And then also DevOps need to know both sides. But when the developers and the operations actually work together and do those improvements together, there are actually the people that know both sides and they can actually focus on that and you can eliminate that one silo in between. Integrating all the things of course in the technical perspective it's kind of easy. You just make all the systems work together nice way, but also integrating people across different areas and making them work together. What we have done, we have like of course it's hard to like sales, goes out and sell something and then they come to the developers and do this and then it's like that's not possible. But when they are sitting in the same table thinking about what we are going to sell. It's a lot easier to have the dialogue there and actually offer something that you can deliver. And there are small things too like these slides and this presentation I did together with like I have people reading through my texts and I have these slides. I had really crappy images and graphics and then I went to our designers and said hey this is something that I want so just don't look at the pictures but make them pretty, find something nicer. I kind of liked the outcome, but there was one detail. I don't know if you noticed there was a code slide. Did anyone notice something wrong with that if I go back. This one. So it's nice slide about code. That's actually WordPress code. So it's okay but it was kind of funny that I had the clear idea that I want some code and it was clear I didn't even think about telling the designer that it needs to be Drupal code. He just went out and searched the image banks for nice pictures of code and came with that and then I see it. Okay it looks nice but wait. There's the VP. So I was kind of talking the same language. It's hard sometimes between different people and they don't think the same way as you do and you need to be clear of what you want. But then again it's all the details. And I kind of then talked about it and then like this is a good example of how we can improve the communication and how we can think about what's clear to us might not be clear to others. And there is always something that we assume that others know automatically because we know it. So we need to provide all the details. And automation of course that too is not only about the technical part. It's easy to do the technical part of the automation but also automating like the people workflow. So it comes automatically to people that if they have a problem they don't stay there alone and try to fix it but they can automatically go outside and search for help. That's kind of the behavioral thing. But technically there are lots of those things that you can integrate. The people part is a lot harder. You need to educate people and you need to be present and available for them to notice that they can actually do that kind of stuff. You probably want something more technical. So we have this wonder tools that we have been building and I don't know, I don't go to the details about the technology it's open source and in GitHub you can find it there. But the philosophy that we have tried to build into the system is that it's kind of covering everything that is there like trying to get the tickets from your ticketing system into the production. Everything that is technical and process in between. And the tools of course there is the technical tools that take care of many parts of it like provisioning and deployment and local environments and everything like that. But there is also the actual development of these development tools and usage of this. So it's not like this is the operations tool that we use to put the code in production but actually empowering developers to use the tool and they can actually do some system configuration changes to the servers. And also making it easy to actually contribute back. So of course there's always a way of supplementing to get that we need this and that new feature or this is not working but actually they are also capable of actually fixing them to issues themselves or creating a new feature for them. And by doing that it's also important that those improvements and changes are spread across all the projects that are using our tools so we get the small improvement and it multiplies by all our projects. So it's kind of Swiss Army Knife but instead of like those tools that tend to kind of do everything, it's usually they do everything but not the best way of doing it but try to follow the Unix philosophy of so it's not like trying to ground everything together but just having this framework where you have a best tool for the job and they just work together nicely. So it's like one tool takes the input, then puts the output and the next tool can use it. And same should be in the people process tools like I said talking to the same language different terminology, so understanding what others are saying and when the project is moving for example from sales to developers to DevOps to maintenance so to actual people understand what they are receiving, what they are putting forward in that. And of course most important thing is documentation. There is never too much documentation unless you end up with something like that. Well it's also important that the documentation is there and you can also improve that in every level and like not writing all the documentation from the technical perspective that there needs to be like other people needs to understand it too so it's not just for us but also others. So in general if you kind of step back and see everything that is going around and you do your best thing but you make sure that your thing is not made on isolation but it's connected to everything else around you you see a lot of new improvement opportunities you can make the thing work much better. And if you focus on the change, the process of change instead of like setting goals you can like estimate that we are heading this way and then after some time we should be reaching some level but it's not like the end goal but you just keep going and keep improving and improving the improvement. And really those small changes are worth doing. If you just do them a lot, questions. Where can people find that wonder tools that you talked about? Yeah, it's in the GitHub preposter. Just Google wonder tools it should be the first result. It's under the Wounded.io organization. And open for everyone and contributors are also welcome. Toyota one million ideas in a year. Is that somewhere available or did they share? How do they get these ideas? And it kind of sounded interesting to get some kind of a process. Well basically it's the basis of everything in agile. So it's the agile process that they have somewhere around 50s kind of the lean manufacturing and like that. So maybe they have a lot of material about that. Anything. Remember to share your improvements. Small improvements mother. Let's do it together a lot of those and join the contribution sprints. Thank you and as I also want to improve myself I would really appreciate any feedback you can use that or find the session on the gone website. Thank you.