4 Maps of DevOps – Applying Maps to Find and Manage Your Value Streams

We will then get into the 4 maps of DevOps. And then dig a little deeper around how those maps interact with each other, and how you might scale this kind of practice across an organization before we wrap up and do a Q&A, which I’ll be online live for during the event. So let’s start with talking about some problems.

 We live in a world now where everybody is expecting instant gratification, everybody is expecting to be able to get things at their fingertips, we all carry these black rectangles around with us, which we expect to be able to download an app or look for information or buy a service. And we expect this to happen on demand whenever we need it. And really, we’ve moved from this world of technology where we were buying for efficiency, we were buying for cost because technology was very expensive to one where we were being able to consume that technology, to integrate it and build more complex and more interesting and bigger things, and to one where now the customer is really driving, it’s all about the experience, it’s about how do we provide the best experience, we need to be able to do that as quickly as we possibly can. So it’s really about moving towards this idea of accelerating our value delivery capabilities. And there’s lots of tools out there that will help you accelerate those value delivery capabilities. And they work to be able to help you automate and understand how you deliver value to your customers. But some of the problem comes because these efforts fail not from a lack of clarity, not from tools, the tools will take you so far, but we still need to deal with how we organize?

 How do we interact across Silos? How do we understand the work we’re doing as we bring in these new paradigms? What does that actually mean for the way that we work together? So that was the problems. So now let’s talk a little about how DevOps helps us solve these problems. So what is DevOps? So this is a definition I commonly like to use.

People process and tools working together to enable rapid and continuous delivery of value to customers. And when we look at this, we often find that we spend a lot of time focusing on the tools, the tools that we buy and we implement to help us accelerate and automate these processes and practices.

We spend a little bit of time on the processes but sometimes we end up automating processes without really thinking about how we need to reinvent them. And we hardly ever spend anywhere near enough time on what this means for the people involved and how the people need to change as we adopt these new ways of working. And change is hard – introducing change, it can be a risky business, we already have organizations that deliver value. And as we introduce change, we’re also potentially introducing risks. So how do we possibly manage all of this? Because it’s not always an easy thing to do.

Some of the things that we have in the DevOps space to help with this are things like the three ways and five ideals popularized in Jenkins books, the Phoenix Project and the Unicorn Project, and the three ways being… the first way being all about creating visibility in the system.

The second way being about creating robust feedback loops, so that the system is able to learn. And the third way is continually iterating, continually learning continually looking at ways of working and improving.

 The five ideals then brought along this perspective from the developer’s point of view about are we able to make changes to our systems?

Right where we are, are we able to do the simplest possible change there? Does that then enable our teams to really focus and have flow and to be happy in the work that they do? Are we creating the kind of culture that we want to work within? Are we then looking at our continuous input? Are we really sharpening? Are we continually looking at our ways of working and seeing if they still serve us? Are we continuing to improve and experiment not just with what we deliver, but with how we deliver it?

Are we creating a culture which has psychological safety built into it where people trust each other to make the right decision and that if a decision is made, it’s one that we can trust or we also trust that we can question it, that we can ask that question as to whether this was why this decision was being made? And the last part of that being focusing on the customer and we’ve got to ensure that the customer is always front and center in the value that we’re delivering, because it’s really the customer that determines what that value is. And all of this is tied up in this idea of the unicorn. And we build out the systems and we integrate these things that we call pipelines as part of this. And pipelines really start with the customers and the customers provide us information, requests, ideas across different channels, forums, focus groups, social media, we might reach out to them and ask questions, and they come to us and say, hey, wouldn’t it be nice if your application could do this? And then we put together teams that might consist of, say, a product owner who’s looking at those requests, and working out how these might be answered and deciding to prioritize what needs to change at the product. And they work with their team to understand how might, how might we all deliver these different pieces, and then they come up with a prioritized list of things that probably we want to do this and this in this kind of order, then the team all together takes the first one of these off and say, okay, we’re going to break that down into the pieces we need.

We’re going to take the first piece of this and we’re going to turn it into code and that code will consist of the application, the tests, and the infrastructure, it will consistent everything as code, so that when our automated pipelines pick that up, they can then build and test and deploy this, which allows us to put valuable product in front of customers, which we can then build feedback loops from, so we can learn. So we got our monitoring, logging, test results, chat ops, ways of being able to learn from the products that we’re putting in front of our customers.

 We then measure to ensure that we understand what’s happening because this charge is a feedback loop. It’s like how do we do this more rapidly?

 The faster we can do this, then the quicker we can learn. And every time we put something in front of the customer, that’s an opportunity for learning. And we measure our ideation♪ looking at business metrics, and we ensure that we’re tying all these together, so we got a complete picture of what our pipeline looks like.

But this is difficult, we’re adopting new paradigms, new ways of working, there’s lots of new and necessary training we need to bring in. And human beings are not necessarily all great at change, we need to get much better at it. And this really means that we go through these stages of, first of all, you introduce this new way by saying, hey, we’re going to automate your delivery pipeline, it’s not [inaudible] enough.

 You go away, it’s just a fad, we’re not going to do that to complaining about it, so you can’t do that, if you do that, you’re going to break all of our systems, it’s way too risky, we can’t possibly do that, to please don’t do that to my system, you’re going to break it and everything will go horribly wrong to, you shouldn’t have done that, to finally maybe accepting it. And this can be a fairly painful process to go through. So we need ways of being able to introduce these new paradigms and these new ways of working so that it drives this curve down so that it’s easier for us to get through this. So we can adopt them and understand these in our context. So that when we see these changes coming at us, it’s easier for us to be able to cope and adopt them. So we’ve covered off the problems, this idea that we’re moving to a world of value delivery, we’ve moved into this, we talked about this idea, how DevOps helps us deal with being able to have faster value delivery. And now we’re moving on to talk about the core of this talk, all about these four maps, and how they can help us with some of these problems that we see. So if we have three ways and five ideals, as I described earlier, we can also have this idea for maps, which kind of fits nicely, it’s 3-4-5. And the four maps fit into this larger concept of flow engineering. And they are really this core and they’re really the core of flow engineering. And they’re there to help us create that direction, to help us reduce that change curve, to help bring people together and align on what our different perspectives are and help us guide our decisions. And they consist of these four maps, outcome mapping, helping us define and clarify our outcomes, doing this ahead of determining any solutions, looking at how can we with our outcomes, look at what it is that we want, and if we do this without solutions, this removes a lot of the biases that we see.

 Looking at value streams, working out where are the constraints in our value delivery, where should we focus in order to improve, how do we make sure that we’re focusing on the right thing.

 Dependency, looking at what else is impacting the value stream, compliance regulation, security, other departments that may not necessarily directly interact, but which we know have an impact on how we deliver value. And capability, looking at do we have the right people, the right skills, the right capabilities, do we have the right systems in place in order to actually be able to achieve these goals. And this isn’t a one-done, this is a cyclical process where we know that we’re going to have to come back and see that once we’ve made the changes that we identified, and we focused and we’ve achieved some of these outcomes, we need to revisit these outcomes and see if they’re still the direction you want to go in.

 This is really a process that we want to go through as quickly as we can and keep an eye on to be able to understand how are we moving forward, are we focusing on the right things. So let’s go through each of these in turn, and we’ll start with outcome mapping. So flow engineering really starts with this outcome mapping.

Because we want to begin with the end in mind, we want to start by first focusing on the outcomes, we want to ensure that we have this clarity of vision, that we’re looking for both our short term and our longer term outcomes.

We might kick this off with a discovery where we look at, hey, if I pick up a newspaper from six months from now, and I read the headline, and it talks about all of the work that we’ve done, what does it say? What does that headline say?

 What does it talk about? Who does it talk about?

 Who’s in the article? Who helped us achieve this? Who was there to support us?

 What is it we achieved? And why did we go about this? And this gives us guidelines, like, what are we aiming for, what are we going to do without defining the solution, we don’t want to be defining outcomes in terms of the tools that we’re going to be putting into place, or the solutions we might have in mind, we want to find out outcomes in terms of the things that we want to achieve, the things that we want to see so that when we see them, we know that we’re going in the right direction.

 We then move on to value stream. And we use our outcomes to help us think about how we might go about solving these because we want to achieve those outcomes, and then we create these value stream maps, we start by potentially looking at what are the major areas of delivery, you might start from build and validate to testing and deploying, and what are the different activities that occur in each of those, what happens in business, and what happens in sales if we map these out and we bring everybody together, and they put their stickies, we categorize and we put them into a place and we build out these maps, and they help us identify the places. And this picture here is an example of such an exercise where we worked with a fairly large team to go through this. And the value of this is the visibility it gives you.

I mean partway through this exercise with this wealth management company, we identified that there was actually another value stream buried inside of the the main value stream we were focused on, and that we needed to break that out, we needed to think about how this other stream of activity occurred almost in parallel with the work that they had. And this was eye opening to so many people in the room because it’s finally gave them visibility into how work was being delivered. And this is very easy to do these days, with the mural [inaudible] my personal favorite for this, to be able to create these maps and collaboratively even in these virtual settings, build out this understanding of how value is delivered through the organization.

 We then look at dependency mapping and dependency mapping consists of all of the things that surround it. And we look at this in terms of how do we find all of the things that might be impacting it, have we consider all the regulations, all the compliance, all the security, all the other things that may potentially impact our value stream and we do this, you know, also it’s a collaborative workshop where we come together and we look at this. And there’s a model that I built out in the past called TACO: traceability, access, compliance and operations to act as an anomic to think about what are the things we need to care about, as we go through and look at how our delivery pipelines are creating products, and then we can start to dig into that further to look at who are the actors, what are the threats, what are the things that we potentially need to consist of in each stage of our pipeline, and how as it goes to that delivery, to ensure that we’re looking for the right controls, and how we go about managing and looking at our delivery processes as a whole. And to ensure that we’re really baking safety in to how we deliver our value. And then we look at capability.

 Do we have the right skills? What gaps do we see?

 Do we have the right focus?

 If we start to bring these pieces together, do we have the right people in the right places in the right roles in the right ways of dealing with these things, are there other things we need to bring to the table, do we need to bring in external help, are there additional tools that we need, what other things might be needed in order to help achieve things that we’ve identified. So we’ve gone through the the problem statement in our introduction, we’ve talked about how DevOps helps deal with this by enabling us to do faster delivery.

 We talked about the four maps.

 We went through outcome mapping, value stream mapping, dependency mapping and capability mapping.

 Now we’re going to dig a little deeper about how these maps interact with each other, how they feed into each other to reinforce themselves, as well as being cyclical, they also run in sequence. And how we can then use this to scale this concept and this idea in these ways of working across an organization. So let’s talk about order and context. So typically, when we’re running through one of these engagements with a client, we will start with a discovery session and a discovery session is usually a little shorter. It’s usually an hour or so where we’d run through, like, so, who are the main stakeholders?

 Who are the people that we’re going to need to talk to?

 What are the things that we really want to see as outcomes of this cycle of running through our four maps. And as we go through this, we could start to say, okay, this is where we want to focus this time. And that’s what we’re going to be looking at, this is the really true, the Northstar we want to get to.

 We then move on into our outcome mapping, looking at what are the outcomes we want?

 What are the obstacles that will hold us back?

 What outcomes would we like instead?

 How might we start to think about what we would do to manage and measure some of those and maybe look at where the best areas to focus are and start to prioritize those outcomes, which ones are truly aspirational outcomes, and which ones are things that we can deal with within the near term, or which ones are dependent on those near term outcomes that we might want to move on to next.

 This, in turn allows us to create this outcome roadmap, this roadmap of shorter, medium long term outcomes that we’re going to be targeting.

 We can then move on to value stream mapping, looking at where our constraints in our value stream and build out our future state maps, looking at what is the state of our value stream that we would like to see and so we can start to say, okay, what are the things we need to do and to move? And that allows us to look at this idea of friction removal, what are the things that we want to adopt, that will allow us to reorganize our value streams in order to be able to deliver more value faster to our customers and improve our delivery capabilities?

 Then we look at dependencies and we look at regulation and compliance and security and other areas in the organization that might potentially also be impacting our value streams, but indirectly, and we look at how are those things interacting with the system and what can we do to start to either decouple or incorporate them into the pipelines and into the value streams as we’re delivering?

 That gives us all of these external needs too that we need to make sure that we’ve taken care of, and we can include in our overall model.

 We then move into capability mapping where we’re looking at, well, now that we understand all these pieces, what are the things that we need? What are the resources? What are the skills?

 Who are the people? What are the things that we need to have there in order to be actively able to deliver this, which gives us a roadmap of the different pieces. And I use resources in the general term here, not to refer people but skills and systems, as well as people. And the four maps, then here, these are what we’ve been talking about, the core of this flow engineering idea. And each of these maps, the outcomes feed into each other. So outcome maps allow us to in forms of aspirations, it gives us a clarity around… of purpose around the friction that we’re removing. So when we’re looking at, well, how could we possibly solve this, we now have some ideas of the outcomes we want to achieve by removing them, which allows us to help prioritize what potential solutions there are and how we might go about designing those solutions.

 Once we’ve understood what those look like, we can then say, okay, now we have these things removed, we can use that to feed into the external needs, where we’re looking at this if it still needs changing, how might we need those external influences change?

 How do I make sure those external needs are taken care of in the way that we’re going about building out our solutions to the problems that we see? And then we move into this idea of the resources and we look at okay, now that we’ve got our outcomes, we’ve got our different solutions for the friction, we’ve looked at our external validation, we’ve got all of these different pieces, what do we need in order to make that happen?

 We can look at that in our resources roadmap. So now that we have all of that information that we’ve collected, and all of these pieces, we can start to prioritize them. And that, in turn, allows us to build out a prioritized… what we call a flow roadmap. And this map is something that we can use to prioritize all the bits that we have and look at, well, where do we want to start?

 What are the first things we want to do?

 What’s the most valuable thing we could work on? And we look at things like custom delay as a way of looking at how we do this, how we prioritize these items. So this is a way of looking at this and this is of course, a cyclical process, where we know that we’re going to have to come back and see that once we’ve made the changes that we identified, and we focused and we’ve achieved some of these outcomes, we need to revisit these outcomes and see if they’re still the direction you want to go in.

 This is really a process that we want to go through as quickly as we can and keep an eye on to be able to understand how are we moving forward, are we focusing on the right things. So let’s go through each of these in turn, and we’ll start with outcome mapping. So flow engineering really starts with this outcome mapping.

Because we want to begin with the end in mind, we want to start by first focusing on the outcomes, we want to ensure that we have this clarity of vision, that we’re looking for both our short term and our longer term outcomes.

We might kick this off with a discovery where we look at, hey, if I pick up a newspaper from six months from now, and I read the headline, and it talks about all of the work that we’ve done, what does it say? What does that headline say? What does it talk about? Who does it talk about? Who’s in the article? Who helped us achieve this? Who was there to support us? What is it we achieved? And why did we go about this? And this gives us guidelines, like, what are we aiming for, what are we going to do without defining the solution, we don’t want to be defining outcomes in terms of the tools that we’re going to be putting into place, or the solutions we might have in mind, we want to find out outcomes in terms of the things that we want to achieve, the things that we want to see so that when we see them, we know that we’re going in the right direction.

We then move on to value stream. And we use our outcomes to help us think about how we might go about solving these because we want to achieve those outcomes, and then we create these value stream maps, we start by potentially looking at what are the major areas of delivery, you might start from build and validate to testing and deploying, and what are the different activities that occur in each of those, what happens in business, and what happens in sales if we map these out and we bring everybody together, and they put their stickies, we categorize and we put them into a place and we build out these maps, and they help us identify the places. And this picture here is an example of such an exercise where we worked with a fairly large team to go through this. And the value of this is the visibility it gives you.

I mean partway through this exercise with this wealth management company, we identified that there was actually another value stream buried inside of the the main value stream we were focused on, and that we needed to break that out, we needed to think about how this other stream of activity occurred almost in parallel with the work that they had. And this was eye opening to so many people in the room because it’s finally gave them visibility into how work was being delivered. And this is very easy to do these days, with the mural [inaudible] my personal favorite for this, to be able to create these maps and collaboratively even in these virtual settings, build out this understanding of how value is delivered through the organization.

 We then look at dependency mapping and dependency mapping consists of all of the things that surround it. And we look at this in terms of how do we find all of the things that might be impacting it, have we consider all the regulations, all the compliance, all the security, all the other things that may potentially impact our value stream and we do this, you know, also it’s a collaborative workshop where we come together and we look at this. And there’s a model that I built out in the past called TACO: traceability, access, compliance and operations to act as an anomic to think about what are the things we need to care about, as we go through and look at how our delivery pipelines are creating products, and then we can start to dig into that further to look at who are the actors, what are the threats, what are the things that we potentially need to consist of in each stage of our pipeline, and how as it goes to that delivery, to ensure that we’re looking for the right controls, and how we go about managing and looking at our delivery processes as a whole. And to ensure that we’re really baking safety in to how we deliver our value. And then we look at capability.

 Do we have the right skills? What gaps do we see? Do we have the right focus?

 If we start to bring these pieces together, do we have the right people in the right places in the right roles in the right ways of dealing with these things, are there other things we need to bring to the table, do we need to bring in external help, are there additional tools that we need, what other things might be needed in order to help achieve things that we’ve identified. So we’ve gone through the the problem statement in our introduction, we’ve talked about how DevOps helps deal with this by enabling us to do faster delivery.

 We talked about the four maps. We went through outcome mapping, value stream mapping, dependency mapping and capability mapping. Now we’re going to dig a little deeper about how these maps interact with each other, how they feed into each other to reinforce themselves, as well as being cyclical, they also run in sequence. And how we can then use this to scale this concept and this idea in these ways of working across an organization. So let’s talk about order and context. So typically, when we’re running through one of these engagements with a client, we will start with a discovery session and a discovery session is usually a little shorter. It’s usually an hour or so where we’d run through, like, so, who are the main stakeholders?

 Who are the people that we’re going to need to talk to? What are the things that we really want to see as outcomes of this cycle of running through our four maps. And as we go through this, we could start to say, okay, this is where we want to focus this time. And that’s what we’re going to be looking at, this is the really true, the Northstar we want to get to.

 We then move on into our outcome mapping, looking at what are the outcomes we want? What are the obstacles that will hold us back? What outcomes would we like instead?

How might we start to think about what we would do to manage and measure some of those and maybe look at where the best areas to focus are and start to prioritize those outcomes, which ones are truly aspirational outcomes, and which ones are things that we can deal with within the near term, or which ones are dependent on those near term outcomes that we might want to move on to next.

This, in turn allows us to create this outcome roadmap, this roadmap of shorter, medium long term outcomes that we’re going to be targeting.

We can then move on to value stream mapping, looking at where our constraints in our value stream and build out our future state maps, looking at what is the state of our value stream that we would like to see and so we can start to say, okay, what are the things we need to do and to move? And that allows us to look at this idea of friction removal, what are the things that we want to adopt, that will allow us to reorganize our value streams in order to be able to deliver more value faster to our customers and improve our delivery capabilities?

Then we look at dependencies and we look at regulation and compliance and security and other areas in the organization that might potentially also be impacting our value streams, but indirectly, and we look at how are those things interacting with the system and what can we do to start to either decouple or incorporate them into the pipelines and into the value streams as we’re delivering?

 That gives us all of these external needs too that we need to make sure that we’ve taken care of, and we can include in our overall model.

 We then move into capability mapping where we’re looking at, well, now that we understand all these pieces, what are the things that we need? What are the resources? What are the skills?

 Who are the people? What are the things that we need to have there in order to be actively able to deliver this, which gives us a roadmap of the different pieces. And I use resources in the general term here, not to refer people but skills and systems, as well as people. And the four maps, then here, these are what we’ve been talking about, the core of this flow engineering idea. And each of these maps, the outcomes feed into each other. So outcome maps allow us to in forms of aspirations, it gives us a clarity around… of purpose around the friction that we’re removing.

So when we’re looking at, well, how could we possibly solve this, we now have some ideas of the outcomes we want to achieve by removing them, which allows us to help prioritize what potential solutions there are and how we might go about designing those solutions.

 Once we’ve understood what those look like, we can then say, okay, now we have these things removed, we can use that to feed into the external needs, where we’re looking at this if it still needs changing, how might we need those external influences change?

 How do I make sure those external needs are taken care of in the way that we’re going about building out our solutions to the problems that we see? And then we move into this idea of the resources and we look at okay, now that we’ve got our outcomes, we’ve got our different solutions for the friction, we’ve looked at our external validation, we’ve got all of these different pieces, what do we need in order to make that happen?

 We can look at that in our resources roadmap.

 So now that we have all of that information that we’ve collected, and all of these pieces, we can start to prioritize them. And that, in turn, allows us to build out a prioritized… what we call a flow roadmap. And this map is something that we can use to prioritize all the bits that we have and look at, well, where do we want to start?

 What are the first things we want to do? What’s the most valuable thing we could work on? And we look at things like custom delay as a way of looking at how we do this, how we prioritize these items. So this is a way of looking at this and this is of course, a cyclical process, but this is something you can work through fairly quickly.

Each of these workshops only needs to take a few hours to come through and get a much clearer understanding, and it really helps to get everybody aligned, because you’re collaboratively bringing people together in a truly generative process to look at how do we create these pieces together to get a common understanding of what it is that we’re going to be working on, and where we should focus. But of course, most organizations have more than one value stream, more than one way in which they deliver value and as we move forward and introduce these four maps, these value streams themselves are going to need to change and value streams are typically going to be made up of products, and these products are going to be managed into each of the different value streams and a particular product might even be taken out of the value stream. So value streams are dynamic, They’re going to change over time, but we really want them to be fairly long lived. And then we can use these maps to help manage those changes themselves as they go through and look at, okay, how do our outcomes change now if we’re not going to include this product as a part of value that we’re delivering to the customer?

 But with all of this change going on across multiple value streams, it would be… it would be very difficult for sort of one group or even the group itself to potentially do this.

 So we need a way of supporting this. And for this, we propose this idea of a flow enablement team, this idea of a team that helps introduce these new practices, and this is, if you read things like the sooner say, the happier book, the ways of working team is a similar concept, this idea of a team that is focused on introducing new practices, introducing coaching and in the case that we describe this flow enabled team, this idea of being able to use flow engineering, these four maps, as well to be able to help identify and focus on where to… where do we help improve?

 How do we design the right experiments to focus on the outcomes that we need in order to truly deliver value? So with all of that in mind, and all of these great pieces, are you convinced yet?

 Because if you’re convinced, now what can you do? So we’ve… there’s lots of great information about flow engineering and value

 stream mapping on both our website and our partner Visible run by Steve Pereira, his website as well. And agenda shift is a great resource, too, Mike burrows work there is fantastic.

 I love the the outcomes focused nature of his work, and I highly recommend checking it out. And the PBSSH movement Sooner save a happier♪ by John Smart and [inaudible book name and author name]. And Simon wrote his book all about adopting business agility, I’d highly recommend reading it. And if you want to sign up for the community, the link to do it is here. And on the other side of the slide here is the… is our value delivery book that Steve and I are putting together that’s going to dig a lot deeper into a lot of those flow engineering concepts and give you some real world examples of where we’ve applied this and the kind of things that we’ve run into and how it has helped organizations. And, with all that said, so we’ve run through our problem statement, this is what we see, this is the problem we’re looking to address all around a world moving to value delivery, to how DevOps helps you accelerate your value delivery capabilities, to how we can use for maps to help us collaborate together to [inaudible] and visibly create and identify where we want to focus to dig in deeper into how those maps reinforce each other and how you might scale that across your organizations. So let’s wrap this all up and then we could get into Q&A. So, to look at the four maps.

 Here’s three takeaways for you. So let’s start with the outcomes, not solutions, let’s focus on… when we start to focus on the outcomes without solutions it removes a lot of the biases that solutions bring to the table with them. And by having the outcomes of what we’re looking to achieve will often come up with some very surprising results of where it is we actually need to focus in order to achieve the things that we’re looking to achieve.

One of the concepts that I often bring to the table here is this idea, if you look at the nine steps of solution selling, it’s very common, especially as technologists that we end up focusing on step seven, which is really the solution has already been determined and we forget about the first six steps, which are determine what the problem statement is that you’re trying to actually solve, ensure that you have the data to validate what those are. And so this is something that I’d recommend looking up, start to understand, am I really starting from the problem I’m looking to solve or do I already have a solution in mind and really, I’m just trying to implement a solution?

 Plan for small incremental changes, don’t boil the ocean, don’t try and change everything all at once.

 One of the good things about four maps is it will give you that small incremental step, that first piece that you need to take and look at that and say, okay, this is the thing that I need to do first to make a small incremental change to the way that I’m working today to move me to that next step. And that’s critical because, another way we can reduce that change curve is by having just smaller incremental changes, rather than massive big bang [inaudible], we’re gonna be agile tomorrow type changes, which are really incredibly disruptive and very, very, very rarely actually effective in delivering what they’re expected to. And the last part is that the value is in the mapping, not the map.

 The flow roadmap you get at the end is useful as a guidepost but it’s going to continually change, it’s going to give you a good idea of what are the next few decision points I’m going to need to make, what information do I need for those decision points to be able to make them, and then what are the things I’m going to try in order to be able to experiment and build out and get the information I need to be able to make those decisions.

But the value is really truly in the mapping exercise and bringing people together to run through these mapping exercises because the clarity and the alignment and the collaboration that that enables is phenomenal. That’s really where you will see the value. So I really highly recommend running through these exercises.

With all that said, there’s a really, really short feedback survey that I would love it if you fill out. I’d love some feedback about this talk, what I could do better, what you’d like to see more of, what you’d like to see less of.

 There’s only one question you have to answer. But if you’d like to give us your email, then we will sign you up for our email list, and we’ll send you more resources like that enabling flow book, which will be hopefully ready by the time this airs as well. So thank you very much. It’s been a pleasure and I look forward to talking to you on the day.