 Welcome to this session, Four Maps of DevOps by Peter Madison. We are glad that all of you can join us today and Peter also with us. Without further delay, over to you, Peter. Okay, thank you very much. Welcome, and I'm looking forward to running through this little presentation. It's all about finding ways of applying maps to help manage your value streams. And we call this the Four Maps of DevOps. It's based off some practices that have been developing called Flow Engineering. So who am I? I'm Peter Madison. I'm a coach, a consultant founder of a company called Zodiac that helps organizations adopt new ways of working. And I've been many things in my career from an IC to a director running platform engineering to running my own consulting company. So quick rundown of what we're going to be talking about today. We're going to run through this talk map and a quick introduction to the industry was changing while that's looking like. I'm sure you've had a lot of this a day, so I'll run through that quickly. We're going to talk about DevOps and how DevOps helps us make changes into these environments. So we're going to talk about how Four Maps can help you construct a model for this. And we're going to dig a little deeper into how they feed into each other and how they've been applied in the wild. Before we wrap up with some Q&A. So let's run through this introduction. So in a fast paced world customers demand and stratification where we're tied to these these wonderful little black devices which we can then use to collect information to contact people to communicate to use them for all of these different purposes. And we expect to be able to instantaneously get the things that we're looking for at our fingertips. And we've moved from this world where it was very expensive to switch between suppliers. And there was very initial initially high investment and steep learning curve to one where we have technology we could integrate and commoditizing of the general IT capabilities to what we're allowing us to grow and build much more much larger much more complex systems. And with this came a reduction in investment horizon and they are moved away from CAPEX and into OPEX. And now what we're seeing is very much the customer driving the value message the customers driving this and we say cheap to set things up it's very quick to be able to start to get going and build the systems that consume services that we can then do together and as a consequence of this as well customers are have an expectation of a very fast return on investment. There's lots of tools that help with this. And they will help accelerate value delivery, but often our efforts with these fail from a lack of clarity not tools. The organizational structures that we find ourselves in the silos the lack of alignment to a common vision. That's the lack of visibility into what's going on across the organization gets in the way of us really truly getting the value from these tools that we implement to improve our value delivery. So, that's the introduction it's all about value delivery and how the world is changing and how we need to help find ways to help accelerate this in our environments. Let's talk about DevOps so DevOps is all about people processing tools working together to enable rapid and continuous delivery of value to customers this really aligns well with our value delivery. And that's the message but we find organizations focus so much on the tools and bringing the tools into place that they forget that they also need to change the processes and quite often forget that really we should have started people what is it the people need how are we going to actually work together to really bring value to the table. These change requires us to be able to understand what's going to happen in the environment we see this as an awful lot of risk, it's, it can be threatening to us when we start to introduce these changes, and that we're going to modify how the organization is operating. What is the impact. Is this something we can do if I, if I start to make everything different. What's that mean for me. We have these models that DevOps very helpfully provides us the, there's three ways and five ideals that Gene Kim popularized in his books Unicorn project and the Phoenix project. And these, these give us models that we can use and to help understand and start to break down some of these complex problems and use and apply DevOps to them. So the three ways being first way is like make the system visible, see what's happening by and by doing that as we start to measure we can start to understand and improve it to creating feedback loops understanding through monitoring and looking at what happens when we make these changes, so that we can understand how that we can change the system as consequence of that to then continually iterating as being the third way. And this also feeds into the five ideals making sure that we're retreating this locally in as simple way as possible and looking at how we can then have more focus and flow and joy in the work that we're doing, and then continually improving aligning very well to the third way without the ideal to continually improving that but to do all of this we need that in prime to psychological safety, and ensuring that we're focusing on what our customers need. So, when we think of DevOps we think of things in terms of these pipelines and if we think of it, not just in terms of the tooling and the automation, think about, what is the end to end stream value that we create what is the end to end pipeline that is the end to that so if we have customers that provide us requirements and channels forums folks with social media and we might put together a delivery team that delivery team might consider stuff somebody who owns the product that's going to be delivered and they might have a bunch of team members are going to collaborate with them and together they're going to work out how do we do this and the together they'll come up with a set of stories and prioritize what needs to happen. They'll they'll break these down into smaller pieces they'll pick them highest priority the biggest business value and they will break the standard smaller pieces, and they'll start to work and then they'll turn into code into application code and test code and infrastructure code. We'll then have our CI tooling pull out things into an automated pipeline which will automate build the test deploy of it, so we can push out a product that we can give to the customers. But for then we need our feedback we need the monitoring the logging the test results, which can come back delivery team and the customers so that we can say, Okay, what. How did you feel about this was this what you were looking for, as we start to then work on iteratively and incrementally delivering more more value. And we can then measure to start to understand how we can possibly improve on this what can we do to help make this go smoother and better and faster, so we're really delivering value. And as we introduce all of these new paradigms these new ways of working this new knowledge. We've also to ensure that we're still meeting all of the existing commitments in the organization. And this often ends up with us ignoring the changes that comes into them complaining like, I don't want to do this this isn't going to impact me if you change the way that I do things everything's going to go horribly bad to please don't do this to to sulking about. Well, now you've done it everything's going to break you've made changes and it's not going to work to finally accepting it. And our role is change agents and our role as with DevOps is to try and help drive this change adoption curve down so that we can have a the impact that we're looking for, while still allowing people to be able to come together and actually understand and not be so impacted by the change that we're unable to move forward. That's that's about the introduction about value delivery about how the world is moving to this value delivery model to the how DevOps gives us models and ways of looking at changing that but how the introduction of these new practices these new ways of working creates a lot of change and bad in itself is something that it's difficult for people to deal with so we need, we need to further ways of helping us be able to make this down and this is where for maps comes in. If we have our three ways and our five ideals, the four maps can be considered as a way of getting us from one to the other to help to bring out from the these principles and these ideas, the concrete steps that we can undertake in order to start to get going like to start to say okay well if I if I want to create that because what do I need to actually do what does that that look like and what are the steps I might want to take to do it. The core of flow engineering of these four maps, the, the four key maps to find the direction aligns stakeholder perspectives and guide our decisions as we move through the process so we've got outcome mapping which helps us define and clarify our outcomes. We have value stream mapping which helps us identify and address flow constraints. We have dependency mapping which helps us visualize and address the external needs of the system. And we have capability mapping which helps us measure and address all of the internal needs like what do we need to actually make these things happen. We've. So flow engineering starts with the outcome, begin with the end in mind. We, we want to ensure that we're focusing on the outcomes and creating that clarity of vision by working to team we want to create our alignment first so that we can start to understand what is the outcome we want why other reasons we want to get there what are the obstacles that we might need to overcome and what can we do to overcome those obstacles, and we can then help find those that and that in itself will provide us with a path forward that we have we now end up with a backlog of impediments that and those impediments are a path those are on that that is what we need to do to move forward. Move on and use that to guide us in finding more friction with value stream mapping looking at where in our system might there be friction to value stream mapping providing a time diagnostic at the end to end system. In this particular example with this this company we were working through and then the top part of the board we very quickly realized there was actually a sub value stream nested value stream inside of the larger one which needed to also be mapped and so we started to build that out and understand what actually happens in order for the overall end to end system to work. When we look at outside of the system at dependency mapping want to look at what things are also impacting other regulations or compliance that we need to ensure that the system is inviting to other other things inside of our organization that we need to make sure are satisfied. Other technical dependencies that we need to ensure that we take care of and understanding and mapping those stakeholders is critical to looking at that end to end system. We also need to understand and look at capabilities so if we understand what the outcomes we want to we can start to break down and look at well what capabilities do we need in order to achieve those outcomes. And that will in turn give us the ability to build out the right capabilities to take the right courses bring the right skills to the table to help us reach the outcomes that we're looking for. So we talked to value delivery how the world is changing as a consequence of that we've we've talked about how DevOps gives us models to help us accelerate our value delivery practices, but how that also introduces a lot of change. We talked about how the formats can help us quantify and what it is that we need to do. And we'll now we're going to dig a little deeper into how these maps are interrelated and provide some examples. So, so in terms of order and context if we if we run through this we're going to start with discovery we're going to look at what is the situation what is the situational awareness that we have of where we are today. And so that we can start to design where we want is we want to go, because we have to understand that baseline we have to be able to quantify where we are as a baseline in order to be able to actually start to create measures of where it is we're going to go. We can't just say what we want to be faster faster isn't going to be enough like how much faster what is faster than to mean faster might mean different things different people. We need to come up with more concrete quantifications of of where we want to go to so that we can actually start to engineer our solutions around that. And we start with our outcome mapping start with what are those outcomes that we want. And if we start to break those down, what are the more short term outcomes or the outcomes we can achieve faster than the and which ones are more aspirational in nature. And that in turn will create a map of those outcomes. We will also look at value stream mapping so that we can now look at the time diagnostic like where are the bottlenecks in the system where are the problems we can start to apply a look at how we might apply lean practices over the top of the actual delivery system and that in turn will also provide a map of opportunities where we can look at improving. And then we'll look at dependencies other other things outside of the value stream that will will impact our ability to achieve those outcomes of the other things that we need to be aware of other stakeholders that will have to contribute to what we need to create. We'll look at that as create our external map dependencies on the system and look at capability maps so the, what are the capabilities we need in order to achieve these outcomes and that in turn will create our map of systems and skills and capabilities that we're going to need in order to in order to be able to create our overall view of this and these of course are four maps that we've been talking about. In turn, these outcome map will feed off our other maps so the outcome map will inform us of our aspirations treats, creating a clarity of purpose. The friction map will improve our external maps around knowing our outcomes delivery flow and forms where we have our gaps excel map will help us say now we can look at what resources we need and identify the gaps. All of this then gives us a number of things which we can prioritize a number of activities that we can start to look at prioritizing we could standardize them and build out a prioritization and use that as our flow roadmap or a model for like where do we want to go what do we want to tackle first what are the first sets of outcomes you want to target and what is it that we need in order to be able to achieve this. This in turn. So here's an example of how we've gone about playing this so we working with a very extracted high level view. Working with a company to help them understand in a very complex delivery system where they're delivering software into into other companies and how do they like improve the customer employee satisfaction they want to also move into the North American market and they're looking at how do we achieve these these these outcomes we've got targets and goals and what we're looking to do but we can see that our. Our systems are working quite the way we want to so from there we use that to guide. Our conversations around looking at the value stream like how do we actually do delivery today how long do each of these steps take how much time do we spend waiting how much rework is there in the system. What are what are perhaps some experiments we could run to introduce changes into that system that might allow us to be able to deliver faster and have better feedback. We look at dependencies and dependencies from all of the different parties that needed to be involved across this complex system, and ensuring that we understood how each of those needed to interact and looking for opportunities where we could simplify the or those or decouple those dependencies to allow the delivery system to flow more smoothly. Then also look to capabilities like what are the capabilities that they don't have that they need in order to be able to enable these outcomes and how can we bring those to the table, what things do we need to do. And through going through this process and creating that prioritization and then taking being to take those actions we immediately started to see the improvements in the system. This immediately allows us to start to look at how we do things we we pointed out. We could very easily have the environment creation time by lining up the DevOps resources, removing the ticketing pieces that was going on there's a lot of handoffs going on in the environment creation piece that didn't need to happen. And so those activities like that that we undertook and could demonstrate the immediate benefits of being able to get environments up and running faster which allowed them to start with their experiments faster which allowed them to deliver quicker, which is a great benefit. So then how do we scale this so if we think that we have we have value streams running across the organization and in those value streams will have a number of different products which will probably be contributing to them. So as we look at the end to end value streams the the stream of work that is creating value for our customers. We will have products in there and those products will come and go so we need a way of being able to understand and manage this and as we start to scale across the organization. The effective way to do this is to build this flow enablement team. So, as we start to provide guidance on the introduction new practices they'll start with coaching development and application of these flow engineering practices and they'll help build these within the organization. So these ways of working or flow enablement teams can be a very effective way to help with being able to move these things forward. My telegram is buzzing like crazy. The another important piece now is great hey I'm convinced. So flow engineering in the wild you can find out more at zodiacs website my company's website and visible.is who's a good friend of mine and see prayer that I collaborate with on the flow engineering models. And him and another guy who's part of our community called Andrew Davis have a book coming out soon. You can join our community at flow collective.org. This is a great place to come and discuss all things flow. We set it up because we were finding that just the conversations agile there was didn't go it's deep as we'd like into some of the topics we wanted to discuss is a great place to come and share ideas and talk about everything around value, value delivery leadership, and how you introduce change into organizations and it's a great forum for that agenda shift is another part of my brother's work I really like and appreciate that and some great ideas over there and the, the bvsh movement that I also partner with on initiatives to help introduce and bring a lot of these ideas to the forefront and help organization to top them. So with that, by way of wrap up and q&a we've run through quite a lot sounds like a lot of work. But a lot of it boils down to this is like start with the outcomes not solutions. I often like to explain this when I'm consulting as using the nine step solution selling model is that there's nine steps in solution selling and if what we find is that as technology we often end up starting at step seven which is with the having the solution in mind, we skip the first six. So going back and looking at like what is the thing we're actually trying to solve for properly defining the problem is critical, and going back and working through that process. Before we get to the point of saying hey I've got a solution let's just execute let's go automate let's go faster faster faster taking the time to do that planning pieces essential. And I find organizations often don't spend enough time on that in the rush to adopt new ways of working and don't understand the value that comes from the planning process, not necessarily trying to abide by a static plan, we'll get to that. While the ocean starts more plan for incremental changes into the environment. mapping exercises don't have to take a long time, you don't have to plan for months and months and months and years you want to plan for four to six months out you want to, you want to be able to execute these mapping exercises frequently and be able to do them in a few hours. The value is in the mapping, not the map, the value is in coming together collaborating having the discussion building out this common understanding of what things look like, not in the the resulting map that may come out of that. That's everything about the formats of DevOps in 20 minutes. And if you would like to take survey there's one question to be answered. And if you want to grab the link there or take the QR code then that's. I'm happy to send you some material and connect with me and I'm happy to share more information about how flow engineering works and how it can help you. Okay, thank you very much. Thanks Peter for sharing your experience with us today. Thanks very much. Thanks Peter.