 Thanks, everybody, for having me. I want to especially thank Matt for influencing the voting committee to bring me here so that he could hear me say, process, because we all know that's the reason I'm here. But I'm going to try really hard, actually. Fun drinking game. I'm going to try and say process every time. It's like I went through it last night. There's dozens of them, so I don't know. You might see me slip up, but feel free to take a shot from your flask. So my assertion with this talk is that visualizing your processes will help you communicate, execute, and maintain your transformation journey as you're trying to get progress, progress. I never promised. I never promised progress. So as you're trying to progress with DevOps. So just a little bit about why we're here. We all have different reasons for being here personally. But overall, this event and this series exists because there's conflict in an organization, across silos, across different groups, in an organization, across organizations, different priorities, different incentives. And this affects everything that we do. It adds friction. It adds constraints. It adds difficulty. So my talk is mostly about the most effective means that I've found for alleviating that conflict and improving communication, collaboration, and organizations that are trying to make a change. So here's a fun thought experiment for everyone. Whether you think this is depicting dev or ops, you're horribly prejudiced because it's just a cartoon monster and it doesn't really mean anything. So leave your prejudice at the door. You're just being silly. But really, I mean, we talk about the wall, throwing things over the wall, walls that exist in organizations, even the flattest organizations where there's no separation, everyone's working on the same floor. It doesn't have to be physical barriers. We know that those walls exist in terms of trying to set up organizations so that we can focus and also leave people to their specialties. That comes with problems. So you have lack of visibility, lack of communication, lack of understanding. We've heard a lot about that over the last two days. So I want to talk about value as well. So how many people, I like to ask this question every dev ops day, and it's really entertaining, I think. It's kind of eye-opening. How many people know their company's mission statement? Show of hands. And how many people know their manager's KPIs? Another show of hands. How many people know what actually really makes a big difference to their managers and causes them to be successful, right? Causes your team to be successful. And why does that matter, right? The question is, how do we sell innovation and cultural change and affecting the way that you do things if you don't know your audience, right? If you don't know what's valuable to your audience and what they care about, how can you make that progress? So I want to talk about manufacturing value, believe it or not. We have to understand how we create value in order to improve the process. And there's a few leading challenges to this sort of initiative, right? You hear from Gene Kim talk, and in books he's written, publications, blog posts. He talks about the main challenges to transforming organizations and IT organizations is, in delivering software, is environment creation, tests set up and run, code deployment, and tightly coupled architecture, right? And I think thinking of things in terms of a pipeline addresses all those concerns. So we want to encourage a dialogue across departments about what the business really does and how they do it and how they address these challenges, right? And we can reveal opportunities to improve beyond our own little silo in an organization. So John yesterday was talking about complexity, and that's exactly why tools like visualization exist, because it's really hard to keep all this in your own brain, right? And then try and communicate it to someone so that it actually goes from your brain to their brain in exactly the same state, right? We don't have immutable ideas. Whoops, sorry. And the other thing about manufacturing value is the concept of flow, and that's another thing that Gene talks about all the time. It's referred to as the first way in the Phoenix project if you're familiar. And flow has this constant conflict in itself around the progress of, oh my God. The progress of value against constraint, right? It's always flow versus constraint. It's a constant conflict. And you want to maximize throughput while also maximizing quality. So sort of an old school way of thinking about this, in thinking about manufacturing as well, is a process and technique called value stream mapping. And it comes from lean process engineering and there's an old book called Learning to See that I recommend. It's pretty heavy, but if you really want to dive into this stuff, it's a great book for that. It's really about holistic visualization. So seeing end to end what a process looks like and being able to map the return on investment of putting something into the system and getting something out, value out the other side. And I'm gonna sort of describe a general process map and because your value stream is going to be specific to your business, right? So these are sort of steps that we all understand and we can all talk on the same terms. But you can take this back to your own company and sort of map the way that you do things and reveal opportunities for improvement. And I think that's really important because we get used to pain, right? And organizations, we get used to pain in the way of doing things and we just sort of get comfortable accepting the way things are done because it's easier than trying to re-examine your whole world all the time. But every once in a while we have to sort of step back and look at how things are actually working so that we can make an improvement. So I'm gonna sort of put this in terms of a pipeline where we're shepherding code through a process to manufacture value, right? In realizing something in production, right? For customers. So a very early problem that you have when you think about constraints is that you need something to actually code on for a round. And that brings you to the problem of provisioning and configuration, right? This is something we all struggle with and we have discussions in open spaces and talks about this. You'll see like these are constraints along the process in our pipeline where we have to do all this work to make sure that things flow, right? To make sure that your code has somewhere to go and that place is actually configured and ready. Sometimes you can do this out of band, right? Sometimes you'll do it just in time. These are manufacturing terms for like do it when you need it or do it in advance so that it's ready for when you push code, right? And there's a lot of great tools for this. You'll see configuration management tools. You'll see automation tools. You'll also see things like Jenkins will be used for like spinning up resources where you're gonna be putting code for test environments and whatnot. And I reference a bunch of tools and resources at the end of the talk so if you guys wanna dive into specifics, I've got some examples. And once everything is sort of set up and you have an environment where you can start to evaluate quality, right? Then you wanna make sure that everything that you expected actually works. And that's probably the most challenging part. So our pipeline starts to look like this where we have like local unit testing. You'll have mocks where you stub out systems that you can actually have access to or it's costly. And it's most efficient at this stage because you're closest to the developer, right? So any blocks or constraints that you see here are lessened because you're operating in an entirely local space. And as we go down the pipeline, you'll see increasing levels of testing, right? Increasingly complex, increasingly costly, increasingly time-intensive. And we're always trying to get more towards a production-like system, right? So you also see that when we're deploying to these more production-like systems, we have more intensive tests, right? We wanna make sure that when we go to production there's no surprises. So there's all kinds of investment that you can do here if you are noticing these gaps, right? If you look at your process and you see that things seem to fall over at a certain point, you can address this with testing, right? To make sure that you bypass that block and your pipeline flows, right? So even after the point of like a production deploy, we also see things like feature toggles and A-B testing as ways of ensuring that code does exactly what we want when we deploy it and when it's out in the wild. And the feature flag talk from this morning actually reminded me of a great example, two great examples. Well, one is HP LaserJet firmware. If you guys haven't heard the story of that, definitely look it up, it's amazing. It's about sort of shipping code turned off to on-premise printer hardware where you have no control over how it actually runs, right? That's a really excellent example. And then the other one was like Facebook Chat. If anyone's ever heard of Facebook Chat, like Facebook Chat ran in production for a year before they actually turned it on for everyone. They just slowly started trickling people through the system, right? And so there's a lot of testing in a very mature pipeline and you don't have to start with this, but these are ways that you can sort of examine the blocks and issues in your pipeline where you're bumping into these problems on a very regular basis, right? So these are ways of smoothing out the problems that you might bump into. And it's all really about trust but verify, right? You wanna get as far as you can without like impeding the flow so long as you're checking all the boxes and everything seems fine. And the way we really turn the crank on a pipeline is through automation, right? None of that testing would be feasible if it was all manual, you know? Everyone here knows that manual work is really the opposite of what we're trying to get to here. So we wanna automate things like artifact creation, testing, deployment configuration, scaling, all those aspects where it's going to be very intensive and potentially error prone to have someone manually do the work. So the good news is that you can automate almost all of this stuff, right? If you spend enough time, if you realize that this is something that you're going to have to spend time on or have a lot of issues with not having it automated, it makes sense to have the investment put into automation, right? To make sure that flows. But you can also automate all your configuration and provisioning, right? Like anyone you talk to in the vendor areas is gonna tell you about all the automation that's available for every aspect of your pipeline. So you start to see something that sort of looks like a pipeline. Again, this is highly simplified and you're going to have your own example, but it helps a little bit when you add some bathroom fixtures to make it really look like something that flows. You know, you can go wild with trying to map how you do everything, but really it's the exercise that's valuable, right? It's taking the time to look at things and try and figure out like what you actually take for granted and what are assumptions? What do you think people are working on that they don't actually work on or they hand it to someone else, right? Or it just sits there for three days. So when you go through this exercise, it's usually post-it notes on a board, right? You have a big meeting with a couple of people from different areas of the company. You sit together and you just start throwing up all the steps that it takes to get your code into production and an idea from being unrealized to being successful, right? Being value. And a really valuable way of approaching this is actually going backwards. So when you go forwards, you can be kind of optimistic and take things for granted and say that I would assume that this happens and then that happens. But working backwards from production will actually be more effective because you don't walk the stream as an idealist. So you don't sort of take things for granted. When you're working backwards, you sort of have to re-examine everything in your head and it's a little bit more consistent to work from production backwards. So either way, if you hit a block, if you hit something you don't know, by all means work from the upstream to downstream but traditionally the science says working backwards is a more consistent way. So once you have your pipeline and you've got something that works and you know how the end-to-end process is executed, you wanna actually make sure that that's as effective as possible, right? And if you're improving it, you wanna make sure that your improvements are measurable, that you have made progress. And so you start measuring things like cycle time, you can measure your test coverage, you can measure number of defects per week or number of defects per deploy, whatever works for your organization, right? And your style of deployment. You can measure how long your build takes and any manual intervention steps, which will bring me to my next slide. So when we look at this pipeline and the way that we're delivering value, the biggest constraints and the biggest problems are gonna come from all the manual intervention that happens, right? If you've got the most automated tuned up pipeline for delivering code and somewhere between staging and production is an email to someone who they're gonna get to eventually or hit some out of office alert, then you're really wasting your time on all that automation, right? Like all that automation that cuts you down from three hours to two minutes is totally blown out of the water by three days of waiting for an email, right? So you really wanna make sure that you're eliminating as much manual as possible. And so when we look at this in terms of a pipeline, things like meetings matter. I'm using Brent from the Phoenix project, but anybody who is absolutely critical, like a complete human blocker for any process because they know everything or they're in charge of something and it's not really sure what they're doing, but you can't automate it. It's really gonna get old really, really quick. So you wanna eliminate your handoffs, your approvals, wherever you can and really examine your compliance regulations because maybe you're making an assumption about what's required and maybe it's not actually a requirement for going to production, right? So why would we take the time to bring everybody into the same room and write up a bunch of post-it notes and stick them on a wall and move them around and spend all this time getting everybody to make this map? Because it's complicated and onerous. But the reason that it's complicated and onerous is the exact reason to do it, right? Because otherwise it has to reside in people's brains, it has to live somewhere else and if it is complicated and onerous to do that exercise, that means that it's valuable to do it because otherwise you'd just be able to have one person at random in your organization say tell me how Team X deploys all their code and they can just go and rhyme it off. But because they can't do that and they likely can't, it's great to get everybody on the same page and a value stream mapping exercise is a great way to do that. So what else can we do? What else is awesome about value stream mapping and mapping processes? You get the benefit, you obviously get the benefit of sharing and illustrations. You can easily communicate. When something comes up, you have a problem with the process. You can go and point to something, right? And you can bring that to someone else and they know exactly what you're talking about, right? And it's gonna reveal it something. While you're going along your path automating and removing blocks and trying to optimize, if you can point to specific points and say, this is what we're attacking this week, right? You're gonna have better conversations, you're gonna communicate more effectively and that's another big theme of this whole event. Yesterday I was in an open space and it was actually about hiring, but one of the challenges that I think commonly appears when you're trying to hire in a DevOps world is that you want someone with holistic understanding of an entire system or an entire ecosystem or an entire set of products and processes. And that's like trying to hire a unicorn, right? That person doesn't exist, they don't know what your process is, they don't know what your holistic vision is, but if you've gone through the exercise of mapping everything out before you hire or while you're hiring, you can actually have that person be valuable and productive day one, right? Cause they're gonna come in and know exactly where they're gonna fit and what they can do to contribute. So it's a great training exercise, it's a great way to keep tabs on the fact that if you've got cross-functional teams or people moving through teams, that they join a new team and they're immediately up to speed, right? Jeff yesterday talked about brainstorming failure, right? So when I think about that, I think of trying to establish all the ways that something can go wrong. And we often use checklists for that, but to form a checklist, you're only operating within like a strictly brainstorming function, right? So off the top of your head, how many things can you think of? Well, it's a lot easier to go through that exercise if you've got a visual map, right? Whether or not you're a visual person, you're probably dealing with people with varying degrees of visual acuity, right? Or a comfort with visual communication. So it helps to put those things into context so that you can go down the list and say, well, I think we actually missed something here. We gotta make sure that DNS is switched or we gotta make sure that the CDN is invalidating our cache, right? And those things can be hard to just think of off the top of your head, but if you're following a visual map, it becomes more apparent where the gaps are. Impact forecasting, I don't know if anyone's ever used this term ever. I just wanted two words to go together, but the idea here is, how will a change affect the way that we do things, right? If we swap out component X for component Y, how does that impact the rest of the pipeline? And when we think of switching to Docker or microservices or 12-factor apps or immutable infrastructure, any of those big topics, you want to know how it's going to change what you do right now, right? Whether it's gonna be better or worse, but having a visual representation of the current system and the way that you do things, it's gonna make it a lot easier to sort of tease out these are potential problems and here's where we could go wrong. Another thing is like, I think a lot about backlog prioritization. So thinking about what costs most to delay, right? Or what should I be working on? What's the most valuable thing that I can work on? And thinking about what your top constraint is. Well, if you have a map of the entire process of how you deliver software, how you configure systems, you can look at, you know, this is way upstream and it's three days of delay. So this is definitely a top constraint. This is definitely something that we should be tackling. So again, the definition of done is another thing that it's really hard to just think of off the top of your head, right? Unless you go through an exercise of trying to exhaustively tease out what are all the things that need to go right in order for this to be valuable and deployed successfully in production. And it really helps when you have to go talk to salespeople about, you know, you think it's just a bunch of code and then committing something, but there's actually all of these things involved, right? And so it makes it a lot easier to talk to people who really may not understand all the complexity that goes into the work that they take for granted. And they shouldn't have to really worry about, like, what are all the possible things that could be involved in this? They don't have time, it's not within their domain, but if you have a map you can point to, then everyone understands what the score is, right? And what the cost of doing business is. Another idea, so Steve yesterday talked about process over kill and Byron Miller actually has a really great article on engineering the future backwards. So you can do value stream mapping for current state, but you also do it for future state, right? You can map out how you'd like your system to work and then work backwards. Like what are the things that, what are the requirements for living in this world, this idealized world of where we wanna be? And what's the delta between that and where we are right now? And you can start to form a backlog and prioritize and you can see, okay, we're gonna have to do this and we're gonna have to do that. We're gonna have to start thinking about this and this is gonna be a tough change for everybody. We can start socializing it so that it's not just dropped on people's laps. So really, the whole deal behind this is looking at delivering value as a method of just continuously doing everything that we're trying to do, right? Continuous sharing, continuous automation, continuous measurements and improving culture by being as communicative and as open as possible. And so I think that visualizing process is the most effective way that I've found and I'll say that it's, the disclaimer is that I'm a very visual person, but in times where I've had trouble describing to people what I mean by DevOps when I say DevOps or what I mean by continuous delivery when I say that, it's been really helpful to have the map to point to and the map to walk to get everybody on the same page and I think it's super, super valuable. So we talk about the core tenets of DevOps being experimentation, automation, collaboration, right? Sharing, I think it's a great way of getting people on the same page and understanding is really the key to all that. So I'd be really interested to have an open space or answer any questions if there are any, but thanks very much, that's all I got guys. Thank you.