Hello everybody. Today I would like to talk to you about trust driven development and how this approach can help us in DevOps transformation. Firstly, when we see be the transformation world, what do we think about that in our minds? It can pop up that it will be a change, it will be a change in the ways of working, it will be a change in the tools that we are using. Definitely the change. And if we are going through change, the most important part is trust. And today I will tell you why and how we can transform our organizations. Let's think for a while about the world, what we operate in. It is Vuca World. I hope that some of you have heard about this term. It was defined in the US after Second World War. And this is telling us about four dimensions of our nowadays world. Our nowadays world is volatile, it's arts uncertain, it's complex and is ambiguous. All right. On the other hand, we have our agile world, we have market dynamics, because our iT environment is very dynamic. There are a lot of companies are popping up every day, some startups are shutting down. So the market is definitely dynamic. Then we have unknown requirements. Obviously we as engineers, we know that we have a lot of discussion with the business that they would like to develop something, these would like to earn money. But then they ask us, okay, so how this feature should look like, what it should do. And sometimes we are frustrated, right, because we are the engineers, but they are the business guys. But in reality, right now we need to advise our business folks what to do and how to do it. We solve the complex problems, right? Because we are these to solve the complex problems and complex riddles. And last but not least, we have ambiguous estimations, right? When we develop something, we need to have a founding for that. And our business folks usually ask about, okay, nice feature, how much money does it cost? So we have those four aspects of our agile world, I call it Muka, acronym. So market dynamics are no requirements, complex problems and ambiguous estimations means muka. And it is sort of for me the answer for this Vuca world. Now, if we see the agile manifesto right now, we can see that in every single item, in every single line, there is a trust involved. Because these first one individuals and interaction of our processes and tools. Okay, so if we would like to interact with each other, we need to trust each other, right? Customer collaboration of the contract negotiation. We need to trust our customer that we not will be negotiating and fighting for every single feature. We will be collaborating, responding to a change. Definitely. We need to trust ourselves that we are able, we are capable to respond to the change that is happening. And we need to acknowledge that. And working software, someone needs to trust us. Most precisely, the investors needs to trust us that we will develop, they will put their money and we'll develop their software. So let's think for a while about this trust aspect. Isn't it a little bit of fuzzy? For me as an engineer, I didn't know what does it mean to be trustful and to have trust, to build trust with each other? So what I did, I did some research about that, and I observed that there are two aspects of building trust. The first aspect is cognitive aspect, and the other aspect is emotional aspect. Cognitive aspect is transmitted through thinking. So everything that we think of, everything that we have in our mind, the skills we have, the knowledge we gained, the experience we've got, this is the cognitive aspect of trust. And emotional aspect of trust is transmitted through feeling. So everything that is connected with our intentions, with our openness and honesty, everything that we make people feel, if they are interactive with us, it is emotional aspect of trust, and we call it that. We are in integrity when we have those aspects. So cognitive aspect is more oriented for the results. Emotional aspect is more oriented to the being in integrity as a person. So we have those two pillars. And while building trust, during DevOps transformation and during DevOps practices, we need to think about those two. The first pillar is all about competence, and the second pillar is all about character. So it means that trust is a combination of competence and character. Of us, competence is the cognitive intelligence that we have. We are engineers, so we all know that when we work, we use our analytical skills, we use our logic, we have the specific language. It can be Java language or c plus plus language. But it also can be specific technical language that we are not aware. Even like we are talking about deployment, we are talking about measurements, we are talking about having the ceremonies, like planning, retrospective, and so on, that specific language. And people outside of our domain will not understand that. The same with the data. We use a lot of data, we analyze a lot of data, and we know what does it mean if we are analyzing those records in the database, for example. But this is the meaning for us, for our cognitive intelligence, not for others. We have also emotional intelligence. And emotional intelligence is basically how to recognize and understand our emotions. So when we are in such a state, for example, during the meeting, and we don't understand our emotions, we will not be able to also react properly. So the first things first is to understand in which state we are in and what's going to happen with us and then we can define our reaction on the certain situation. For example, during meeting, it is also recognizing and understanding emotions of others. Because if we, for example, we are doing the planning meeting, we need to understand what's going on in the room for different people. So for example, for product owner, he or she might be worried that the feature will be not taken into consideration or he or she might be excited that there is a new feature coming in. But the team can be worried that it's difficult feature and we are not able to deliver these. So there are a lot of emotions that we are not aware of. And this emotional aspect is for us to understand. So when we embrace our emotional part, then this is the way to build a bit trust and break out the silos. And why I'm talking about the silos in the organization, because this is a clue. This is a crucial part in terms of the DevOps transformation. When you see this picture, there is an example of tools ecosystem for DevOps, there are a lot of different tools that we are using. We were implementing in the companies, or we would like to impediments. And you can see that there are certain domains of the tooling we use, for example, GitLab to build application, we can use chef to deploy the application, Docker to run it, and so on and so forth. These are a lot of different tools and we are keen on implementing those new tools. But if we have domains, we also may have silos, right? So there can be a certain amount of people building the app and then there can be a QA group who are testing the app. Obviously nowadays qas and developers, engineers are sometimes, usually, I guess, mixed in the one team, but this is just a part of this example. We have then people who can deploy the application and run on production. We can have the operations who monitor the application. And that's why if we talk about DevOps, DevOps means, as easy as it is, DevOps means development plus operations. So the shared responsibility, shared goal and shared working ways. So in order to have it, we need to break these silos and build trust. If we will build trust between those groups, we will be succeed. And the tooling is just another example that we will be using. But definitely we need to have trust. Why it's so important, because for example, let's have this example of building and testing software. So we have developers who build the code, we have qas who test these code. And I remember like 15 years ago when I was a Java developer, there was a little competition in the company. Between engineers and the qAs, that the software will have a bugs or will not have the bugs. So DevOps were building software and saying, yes, this software is ideal. Works for me, works for me in my environment. It works, it is perfect. There is no bug. And then this jar file, whatever this app were going to qas and Qas were saying, oh, there's a lot of bugs over there, please raise the tickets to injira. So that was a little competition. And obviously engineers, I was an engineer and we were saying, it works for me, works for me. Do you know that? Yeah, it works for me. And Qas, they were saying a lot of bucks. A lot of bucks. The same story can be between production and monitoring, right? Production people. So let's say building and testing and deploying to production and passing over the app and saying, everything's fine, I've done my work, everything's fine. It break production. Oh, you know, there is operations guys who can fix that. And that is also challenge, right? Because operations guys may say also, oh, the production is broken. That's because of the qas or because they didn't test it or because of engineers. So there's a blaming game starting at this point. And if there will be a trust like this that will have one common goal, one common mission, and people will trust each other that engineers, yes, they did the best work they've ever done, but bugs can be there. Or engineers can trust operations that, yes, operations, they have a lot of good intentions in running on production, but sometimes they need to fix something in the code and we can help them understand the code. If there will be a trust, I'll be helpful for everyone. This is about also exchanging these knowledge. So I met a lot of operations guys who wanted to do some coding part, but engineers said, no operations guys, you just run the applications, we are fixing the bugs and vice versa. I met a lot of operations guys who told me that we are just running the app and everything that needs to be fixed will be done by developer because they build these software. There was an idea a couple of years ago, you build it, you run it. So having the same people building the same people run it. So this is as well this direction that the DevOps is going to. And if we build trust by showing our results, showing that we deliver something, and also showing our attitude that we are open to discussion with other people, then the whole tool chain of our ecosystem can be shared and DevOps can be implemented. As I mentioned at the beginning, there are three aspects that we change. We are changing a lot during DevOps transformation. But there are three aspects that we change. Team structure, process adjustment and tools review. Sometimes we don't need to change, but sometimes we need to review those because team structure. I'm not going to the details about team structure here, but there is a separate book, team topologies, where you can find the different structures for different organizations. But definitely if we review our organization, we think about structure. Do we have the right people in the right team, for example, Dev Qas, dev operations. So we need to have these trust to management and from people that these team structure or restructure will be done smoothly. We may do some process adjusting, so some of our processes, ways of working that we are following right now. It's maybe not efficient or maybe can be improved. So we need to have trust in the group in order to change it, because there will be definitely resistance of people who like the process and there will be some difficulties in trusting the others would like to do it better. So if the group that would like to change something will show their knowledge that they know what to do, they know how to do it and will show the openness that we are here together to work this out, then the resistance can be lower and the tools review. We love that as engineers, right? When we do these DevOps transformation, we do tools review, implement a lot of new tools and so on. But in that case, our management needs to trust us that we know these tools, we will be using good tools and we'll handle that to make our software successful. And then once we have this trust, we as engineers can have the autonomy, right? We are striving for autonomy. You would like to do autonomously, a lot of things. So once we show people results and then show our intentions that they can trust us, we can get the autonomy. And it's even mentioned in the DevOps evolution model on the third stage, that individual, that's the example that individuals can work without manual approvals from outside of the team. It is also about trust because this approval step, for example, while deploying to the production, having this continuous delivery piece, right, usually in the companies, there is the green light that someone manually needs to click in Jira or whatever. So that's this approval. And if these people who make a green light will trust developers, then we can go towards more deploying without approval. And I would like to mention also Brenda Brown here and her quotation, she is a us psychologist and researcher and she said that trust is not being built in big sweeping moments. It's being built in these tiny moments every day. And it works like this, that you have one engineer joining the team and you have the other engineer in the team. And our brain subconsciously is assessing these relationship. Setting up the relationship between us is assessing the two aspects that I mentioned. Do this new guy have the knowledge and can help us in our team? And how about intention of this guy, of this person? And every sweeping moment, our brain subconsciously assess those two aspects. And once it's assessed, a relationship is being built and is built and trust is established. Now I have two example for you guys per programming. That's the first one in per programming we need to have the trust between each other, right? There are some challenges. When I met with the engineers, they told me that there are challenges in the per programming. There is a fear of being assessed. These first things first. I am the developer. I'm a senior developer. For example, doing the per programming with a junior guy. But is it my code senior? Is it enough? Does the other guy will see the value or the other hand, vice versa, that I'm junior guy and I don't feel that my code is good enough in this process. So that's a trap of obviously not for everyone, but for some that we can have. And behind this fear is a fear of rejection. Will I be rejected as a junior and I don't know anything because I don't have this knowledge? Or will I be rejected as a senior because I may not have a knowledge and my attitude may not be right? So this is about fear. And if we will be brave enough to show ourselves, then it helps building trust. Similar with a code review. When we have code review process, we are putting ourselves to the assessment of others, right? The question is if they are assessing my code or if they are assessing me as author of the code. I also need to be courage in order to build trust and to show my code and not to take these comments about my code into me. At the end, I would like to mention about the vulnerability that Brenda defined. Brenda defined the vulnerability people with vulnerability as a birthplace of innovation, creative and change. But what does it mean to be vulnerable? It means to show our weaknesses to others. Like with this example, with this example with the code review or per programming. Because we know systems of vulnerability as a flow or weakness in the computer system which could be exploited and volatile the system, right? So that's our meaning in the engineering of vulnerability. We are searching for those weaknesses and we try to fix them. The human vulnerability is more showing the weaknesses and not to try to fix them. Maybe we can try to fix them at some point. But first things first is to show this vulnerability that yes, we are humans, we have some weaknesses and if we admit that to people, then people will trust us more because our attitude, our intention will be clear. If we are talking about agile or scrum, we also need to be vulnerable to do scrum. For example, quick example for today is retrospective. So we do retrospectives. And in order to have meaningful conversation, we need to show ourselves as we are. A quick example with the metrics from our world. We need to trust each other to show proper numbers, right? These say, give me your metrics and I will tell you whatever you want to hear, right. You know that every single metrics can be work around it, right? We have four metrics here. Like just example, deployment frequency. They said that we need to frequently deploy to production and we need to measure it. Yes. We can split our user stories for so small items that we'll be deploying very frequently and our number will be very high. The same lead time for changes, right? This is about cheating a little bit, right? But splitting work for small chunks so small that the numbers will be perfect. But this is not about that. It's about being true with ourselves and showing our work in these metrics with the meantime to recover. I saw the workaround that when we deploy to production, we deploy to production. But we have these feature flag that says it is invisible to the client. So when we would like to measure the time to recover the system, we can measure up until delivering to production but not showing to the clients, right. And the time will be shorter because at the end of this process, for example, let's say we need to do some tests at the end and not calculating these time at the end we will have better results, but we will cheat the metrics. So in order to have proper numbers and to have proper meaning numbers, we need to have trust together, to be brave, to show ourselves. Then we will be able to build software better, build relationships better, and establish trust. And those three teams will show us the aspect of belonging that we will feel belong in the workplace, because we'll be truly ourselves as well. And at the end, I would like to show you and finish with a quotation from Simon Sinek. These team is not a group of people working together. The team is a group of people that trust each other. Thank you very much. Let me know if you have any questions. I'm available. You can also reach out me on social media and have a nice conference.