My name is Scott Ambler and this is Mark Lines. So we're going to, our presentation today is about how do you create high-performing organizations. So if you happen to have been to my presentation yesterday, that was about high-performing teams. So now we're looking at the, we're going to discuss the organization aspect of this. And we're working through a theme of the, an old Clint Eastwood movie, The Good, the Bad and the Ugly. So I hope some of you are familiar with it at least. It's more of an old guy thing. But anyway, so who are we? So we're the creators of the Disponential Toolkit. And one of the things that we do is we work around the world to help enterprise class organizations to adopt and to transform themselves and to adopt these agile and lean strategies and to become more effective. And that's basically what we do. We're going to share our experiences doing that today. So I'm going to ask you to think outside the box. Some of the, some of the ideas are a bit radical. One of the, one of the messages here today is that there is no official recipe. Every organization is different. Everybody's journey is different.   So that's one of the things we'll talk about. So we're going to work through in a slightly different order in the movie. We're going to start with the ugly and the bad and then Mark will, Mark will get into the good stuff and then we'll wrap it up and we'll take questions towards the end, of course. So the ugly. So what are some of the challenges that we're seeing with agile transformations? The first one is that these change efforts in general, it's not just an agile thing. In general, these change efforts have a reasonably poor track record. You know, as we're seeing roughly one third of these change management efforts are succeeding. And there's many reasons for this. A lot of it is the people leading the transformations, the ones that are doing, that are, you know, leading these journeys often don't have a background in, in this organizational change management stuff. So they're, you know, in some ways they're making up as they go. So we're, what we want to do today is share some, share our strategies for doing this.  This is, you know, what our organization does. Yes, we, we share the dispensable toolkit with the world, but, you know, our bread and butter is to help organizations actually do this stuff in practice. So some of the challenges that we see in the, in the world are some reasonably unrealistic expectations. This is a, Jeff Southerland's latest book, and this is a great book, you know, please don't get me wrong. This is, this is a wonderful book, and I suggest reading it. But look at this promise here. We're, we're promised, you know, four times productivity improvement. This is the implication of this, of this title. And, and sure enough, some teams do in fact see this. And, you know, I've worked with some very dysfunctional teams, and some reasonably dysfunctional organizations.  But what we're actually seeing, and I want to point out this is, this data is not from us. This is from a gentleman by the name of Don Reifer. And he did his PhD in this topic of basically how effective is Agile? How, how well are organizations doing this Agile stuff? And now he runs the business. He continues to study, he continues to research. So he's constantly updating his data. He's constantly sharing his results, he's selling his results. That's how he's making his money, I imagine. And what he's finding is that we're not seeing this awesome productivity improvements. We are seeing some, which is good, but we're not seeing as much as we'd like. And certainly at scale we're seeing even worse. So we need to, you know, part of our message here is we need to be realistic. And I think one of the reasons why we're seeing, you know, not what we were hoping for is because people, particularly senior management is looking for easy answers. They're looking for, they just tell me what to do. I want to transform my organization this year or this quarter to become Agile and then move on. And there isn't an answer like that. This is a continuous journey of many, many years. We need to become a learning organization and strive to get better all points in time. So we need to be realistic. We also need to understand everybody needs to change. It's not just about the workers. It's not just about the teams. It's about the entire organization. And if there's one common theme that I've heard, at least in the two morning keynotes so far at the conference, is that it's really an organizational thing and everybody needs to evolve, not just the people in the trenches. And it's really about culture change. And as we know, culture is difficult. This is an old quote, you know, culture eats strategy for breakfast. Culture change is very difficult and you can't force people to change. So if you sat in on the morning keynote and the talk that immediately followed, there was some very interesting things being said there. And one of it was you can't force people to do things. You have to motivate them. They have to decide to change. So this is very interesting. So we've seen many organizations try to force a framework on people. They try to force, this is this new agile way of working and just go and do it and that doesn't work. People have to accept. They have to be the ones to make the change themselves. They've got to decide to improve and to change the way that they're working to change their way of thinking. So they have to internalize it. So change can be hard, but it can be a lot easier. Part of our message here today is it can be a lot easier if you understand what you're doing. And I think one of the reasons why we're only seeing a one-third success rate is because we have people that really don't understand how to do this change and they're doing the best they can. But there are a few techniques and a few ways of looking at things that are absolutely critical. And this is what we're going to focus on when we get into the good section that Mark is going to work through. So some of the bad things, some of the questionable strategies. So I'm a firm believer in trade-offs and in understanding what works well and what doesn't work well. This is, you know, for those of you who remember the patterns community and then the anti-patterns community, I was actually one of the people that believed in anti-patterns as well as patterns because I believe it's important to understand what works well, effective patterns, but it's also important to understand effective or ineffective anti-patterns that don't work well. What can we avoid? What are bad ideas that we really want to avoid if we can? So one of the things that we're seeing, which is good, is that Agile, the Agile community, is really good at building software development teams. We really are. We're at the leading edge of this, and particularly, you know, the DevOps stuff when you're bringing technical issues as well. We really are good at building these teams, these racing car engines, you know, and we're good at tuning them and tweaking them and getting better performance out of them and better quality out of them. We really are good at that. But then we take these Agile teams, these great racing car engines, and we plunk them into our organizational tractor, and we wonder why we're not winning the race. Well, we all end up with a tractor with a really cool engine. That's better than a tractor without a cool engine, but it really isn't going to get the job done. So if you want to win the race, if you want to be a truly agile business, then you need a racing car. You need to actually look at the bigger picture, and this I think, like I said, this has been a common theme throughout the conference so far is that, you know, we've got to look at the bigger picture and really be asking how do we transform the entire organization. So to sort of, you know, bring this back to one of the things that we're seeing, from a DA point of view, that we see a lot of organizations, they focus on, you know, let's create Agile, Agile Scrum teams or Lean, Lean Combon teams, you know, at the software development space, and then they really sort of ignore everything else. And they don't focus on how do we bring Agile to finance or to procurement or to marketing or to enterprise architecture or to data management or all these other important aspects of the organization. So we really need to look at the overall picture. So we'll talk about that in a bit as well. So one of the challenges with this chart, and this chart is the big poster for the Discipline Agile Toolkit, and one of the challenges that we see in many organizations is they start looking at the complexity that they face. So in Discipline Agile, we basically hold up a mirror to your organizational complexity and we say, hey, this is what you're looking at, here's the stuff that you're dealing with, and you need to deal with it. And a very common reaction is, well, okay, fine, yes, you know, we have finance, we have data management, we have enterprise architecture and all these other things, they're all important. So let's tell the finance people, just go off and figure out how you're going to do finance and go off and figure out how you're going to do data management and so on, which is great, but if they go in different directions, if they start locally optimizing, so if the finance people come up with their finance strategy and it doesn't fit in with what everybody else is doing, then they still, you know, it doesn't work out. And we see this in organizations today. We often complain about the procurement processes in organizations where we often complain about how finance is doing great harm to the agile teams by forcing them to do these big estimates up front and stuff like that. And so these ideas that make sense to finance are actually quite harmful in many ways to the rest of the organization. The strategies that make sense to procurement in isolation that make sense to them are actually quite harmful to the rest of the organization. So we need to look at the bigger picture, we need to be enterprise aware, we need to understand we're all working together and that we're really part of an overall fleet and we've got to move together. So we need to look at this bigger picture. So just trying to divide and conquer will not get the job done and we see this over and over and over again in the organizations because they are dealing with complexity. And so the one way to deal with complexity is to, you know, break it up into smaller chunks. In this case, that doesn't work out so well. We need to, you know, we need to all move together and evolve and improve and learn together in parallel. Hoping the problem will solve itself.  Good luck with that strategy and this hyper competitive marketplace that we're in. I think this isn't going to work out so well. And it doesn't. We've run into several companies that have pretty much committed suicide because they left solving their, addressing their challenges a bit too late. And now they're, you know, they're still sort of alive but it's not looking hopeful for them in some ways. And this is related as well. I'm waiting until there's an obvious crisis. So there's a really good change method called CAUTER, the CAUTER method, if you're familiar with it and it's like this eight step process. And step number one, and it's wonderful, you know, in some situations it actually is quite good. But step number one, it basically boils down to you need to have like a 75 or 80% consensus amongst senior leadership in an organization that you face a crisis. And until you achieve that, you know, you're probably going to struggle to, you know, go through the rest of the step. So you have to have this common understanding that you're in crisis. But unfortunately the marketplace moves so fast now that by the time you realize that you come to this agreement amongst your leadership that we're in trouble, it's probably too late because now you don't have enough time to react. Right? So you've got to be constantly monitoring, constantly, you know, constantly evolving and constantly changing. So this is a bit of a challenge. Also a common theme from the keynote is that, you know, senior leadership knows best. And it's simply not the case that people doing the work are the ones that typically know better. And, you know, part of the theme from the keynote this morning is not to have bosses at all. Not to have these senior leaders. That everybody is a leader. That everybody should be making important decisions within the scope of their responsibility and accountability and all kinds of stuff. And then of course, believing you can transform quickly. This is culture change. This is behavior change. This is skilling change. This takes time. This takes many years. This is a multi-year journey. And yesterday if you attended my talk, I talked about how if you read the DevOps case studies about how these organizations like the Amazons of the world and the eBay's of the world and Spotify's and all this stuff have achieved these awesome results. And they're doing things that are often, almost impossible for your organization to even imagine doing. And they're doing it on a regular basis as if it's basically nothing. And they didn't get to this point just by snapping their fingers and running a transformation project. And a few months later they were awesome. All the stories are the same. It's been a multi-year journey, 10, 15 years sometimes, of a series of small improvements of, you know, run an experiment, see what happens, and improve. So this is a very common thing that we're seeing in these organizations. And all these DevOps case studies are all the same in that respect. So if you're looking for an easy... I've said it before, I'll say it again. If you're looking for an easy recipe, an easy way to do this transformation, there isn't one. And you will more than likely cause yourself significantly harm by trying to do an easy, quick approach. You will probably make the situation worse than what you're currently faced by going for the easy route. Assuming there... Another challenge is assuming everybody wants to change. You know, when your organization is hundreds or thousands or tens of thousands of people, everybody's got different visions. They've got different priorities. They've got... Some people are very happy working in whatever way they're currently working now. They don't see the crisis, or maybe they see the crisis and don't really care, or it doesn't affect them, they believe. So they don't want to change. So not everybody's going to want to make this improvement journey, and yet you still need to help them. An interesting challenge that I'm seeing amongst some of the transformation coaches these days is this idea that, well, if this group over here is really hard to work with or doesn't want to go, why the heck with them? You know, we won't do the hard stuff. We'll just pick the low-hanging fruit. We'll work with the easy groups that want to change, but this group over here, the finance group, or the data management group, or whatever group of people that is, because they're pushing back and they want to be difficult, we're not going to help them at all. Well, that's basically ignoring a serious problem and that will not solve itself. That's going to be a reasonably bad thing for you. So we need to help everybody and understand that not everybody might want that help, and there's different ways we're going to do that. We also see organizations, and this is part of the looking for the easy answer thing. We see organizations adopting a method or adopting a framework, not because it makes sense for them, but because other organizations are doing it over and over and over again. We see companies basically say, hey, what are the people down the street doing? Therefore, I should do it too. This is the level of thinking that we get. And just because other people are doing it, first, did it make sense for them? Maybe, maybe not. You don't know, but even if it did make sense for them, it doesn't mean it's going to make sense for you.  You need to do the right thing for you, not just copy what everybody else is doing. And if you copy what your competitors are doing, you're an also-ran. You're not competitive. You're not innovative if you're doing the same thing your competitors are doing and you're guaranteed to fail in the new world. So we've got to be a little bit smarter about this. And then finally, we need to realize that there is no plan. Yes, you want to do planning and do a little bit about front-thinking and get going in the right direction. But we need to recognize that this is a, this is like driving in Bangalore. You're going to be going all over the place. You know, there's not a straight-line way to get anywhere in this city. And that's the same sort of thing when you're planning a transformation. So just imagine that you're driving home tonight and that's basically what your plan is going to end up looking like. So anyways, Mark, you want to take it over? Thanks, Scott. Can you hear me? Okay, the back? Yeah? Okay. So that's the bad. And I'm going to talk about the good. So first of all, I'm Mark from Calgary and I just want to say this is a real treat for Scott and I. We actually don't have many opportunities to speak together. He lives in Eastern Canada and Toronto. I'm in Western Canada in Calgary. It's a four-hour flight and we independently travel all over the world. So this is good fun for us to actually be on the stage together. So I'm going to talk about the good. I should also say that yesterday, Scott did a talk on choosing your wow, choosing your way of working, which is based on our latest book. Just came out. We're really proud of it. It replaces our first book from 2012. And it's about building those high-performance engines.  Regardless of method or framework that you're using, those methods are not comprehensive and you're going to have to figure stuff out yourself and you can fail fast on your journey to learning or you can pick strategies from the toolkit that are based on certain contexts. You can find one that matches your context. That's going to improve your chances of success. You'll make better decisions. You'll have better outcomes and you'll be more successful much quicker. So that was yesterday's talk, Building High-Performance Teams. Today we're talking about our third book, which is the Executive Guide. It's about optimizing, not at the local level, not optimizing teams, which is this. This is the delivery aspect, but optimizing the organization itself. That is, if you just concentrate on building those high-performance teams and ignore these other areas, you will fail. Because finance and security and release management and data management and enterprise architecture and PMOs, they have their own ways of working. And by the way, those are smart people. They're doing things that what they think is the best way to protect their interests in the interest of the organization. But the problem is that there's a mismatch between traditional PMOs, traditional enterprise architecture authorities and the way your agile teams are working. So what you need to do is get out there and educate them on the new ways of working. They're smart people. They're good people. They just haven't been told what the options are. When we started with that, it was about the delivery team level. And over the last seven years, we've gone upscale throughout the entire organization to help you get better at all these different areas. So I encourage you to look into the toolkit, whether it's governance, PMOs, release management, DevOps. Lots of great ideas inside toolkit. So what I'm talking about here now is this comes from chapter seven of our executive guide. And what we're doing here is we're actually kind of sharing our crown jewels. We're sharing with you how we do transformations at companies. Now there's a difference between a transformation and an adoption, right? A lot of mistakes people make is they take a large-scale agile framework and plop it down on an existing organization without doing the hard things, without doing the necessary transformation. And if you just do an adoption with a large-scale agile framework, it may seem like it's working, but it's going to fall apart over time. So what I'm talking about is the need to actually do a true transformation. And what you see here is the top... This is our roadmap. It's in the book. And the top part of it talks about enterprise coaching. So when you hear about it coaching, there's team-level coaching, but there's also enterprise coaching. And so we have different types of coaches, right? So at the higher level is the enterprise coaching where it's a long-term thing and you do things... I won't talk through all these bubbles. You can read about it later. But we also have team coaching. We can get you through some of the things on this diagram, but we don't have time to talk about them all. So the subject of this talk is essentially how to do the transformation. Now, this picture is also in the book, and it talks about your effort. It's a multi-year effort, and the effort that you put into your transformation activities will vary depending on where you are in your transformation and who you're working with. So I won't go through the details of this because this could be an hour presentation just by itself. But you can see here it includes things like executive education. I'm going to talk a little bit more about that. Your agile training of the team's management. What about the folks in the middle? They need to be agile as well. And by the way, that's a lesson from the trenches that if you don't spend time with your agile managers, you're probably going to run into problems because they're going to be scared. Is there a place for me in the new organization? And yes, there is, is the good news, but you need to educate them on what their new role is. And if you don't engage with them, they will actively undermine you. They will. Because they are under threat, and the only response is to fight back. They can either flee or fight, and they almost always fight, and they're pretty good at winning. Yeah, and we're not perfect. This is a journey for us as well, and this is a lesson we learned, is that my personally in the past have ignored the middle layer too long. But now, of course, we don't do that. In fact, if I go back to the previous one, there is a place that talks about, you know, educating your middle management really, really important. Okay. It's also important in your transformation that you understand who your agile champions and sponsors are, and we recommend that you have a product owner that helps you prioritize, just like on a Scrum team, helps you prioritize where you're going to do your transformation, where you're going to focus your efforts. Now, one of the things that Scott, I'm going to talk a little bit about this in a second, but Scott talked about Cotter and these structured change management methods, and they're really, really good. But the problem is if you use Cotter, add car, whatever it is, often they used to be, and sometimes still are, rolled out in a waterfall fashion. So it's like this month, we're going to deal with that PMO, and next month it'll be architecture, and then next month it will be release management. That is not the way to go. What you want to do is pick the low-hanging fruit from each of those areas and work on them little pieces simultaneously. But you need a product owner to help you understand where you should be spending your time. You need to have that on your teams. We typically get started by doing a very short assessment. We're not big fans of going in and doing a two-month assessment, charging $200,000 and all that. We actually find that we can get a good idea of what the challenges are that an organization faces in three to five days. And yes, maybe we're missing a big sales opportunity, but that's not the point, right? We want to get in and get busy as quickly as we can. An executive workshop, extremely important that you get your executives on board before trying this transformation. If you don't, you're not going to succeed. And it's the same idea where the authorities like Enterprise Architecture and Release Management PMOs are good people, but they just don't understand the new ways of working. You can say the same thing about executives. I mean, they got to be executives not because they're dummies. They're smart people. But often they don't understand the new ways of working. So what we do is we have some workshops with the executives to help educate them that the project-based mentality of the past is kind of from the past and we want to move much more towards a product or release cycle. The annual planning and funding dance that we go through can and should be replaced by more of a rolling wave approach, a much more agile approach. Some of the traditional HR approaches really need to be modernized. And again, they're smart people. So what we do is educate them on the new ways of working, right? And also, let's understand what is our vision for this transformation? What are we trying to accomplish and why are we doing it? And this is an example of a change canvas. You may have seen canvases before. It's essentially putting this vision for your transformation onto one page. And you see here in the middle, I'm going to be referring to the bit in the middle in a second. This is the key vision for a particular company, the kinds of things they want to do. Improve IT delivery dependability. Improve response time to customer needs. Improve quality. Develop high performance teams. And then other aspects of it. What are our success criteria? How are we going to communicate out to our stakeholders? What is the level of urgency? What is the end state that we expect to achieve? Get this, do this in a workshop with your executives, then print it out on a plotter and put it in a public area so everybody can see. Really important. We expect transparency on individual teams. Why wouldn't this be any different? We want radical transparency in the transformation as well. Now this is the exercise that is probably one of the most important exercises in your transformation. It's educating your executives that the things on the left are not as good as the things on the right. And for every organization, this list will be slightly different. So please don't use this. This is a workshop and this is what comes out of the workshop. An agreement from your executive that disperse teams is much better to have co-located teams. Replace the project mentality with the release mentality. Large projects with small. I won't read the list, but you can see part-time allocation of resources to dedicate the team members. In the past, it used to be considered a quote-unquote best practices to have Johnny on 100% utilized. So he was 30% on this project and 50% on this project. And somebody with some tool or spreadsheet says, Johnny's not busy 20% of the time. We need to find a third project for Johnny. And hopefully some of you understand how ridiculous that is because of the cost of contact switching. But we used to think that was the best practice. So we have to educate the executives. There's a better way to go. Really important. When you get, and now this becomes a beacon for the transformation. We print this off, we put it in a public area. Now when somebody says, hey, Mark, we're gonna start this $10 million initiative, I want all the executives in the room to hold each other accountable and say, I thought we said we weren't gonna do that anymore. We said we were gonna go from principle number three, from large projects to small projects because large projects typically fail. And they go, oh yeah, we did say that, didn't we? Let's break that $10 million thing down into a $1 million project and then see how that goes, right? So this becomes extremely important to sort of grease the skids for your transformation. Now in terms of the change management technique itself, now rubber hits the road and we're gonna start to help organizations, we like to use a lean change approach. We didn't come up with this, it's come up by another Canadian, Jason Little and Jeff Anderson. Jeff Anderson. There's a number of people behind this change management method, but it's a marrying of structured approaches with an agile lean approach. So we're using agile to implement agile. Why would we be doing it any other way, right? So I encourage you to read Jason's book, it's quite interesting. He talks about insights, options, and minimal viable changes or MVCs. Insights are pain points. As an example, the team says, oh, you know what, we have to do these detailed business cases that PMO demands that before they let us proceed, it's a 50 page template, it's gonna take a month, why we wish we didn't have to do that? Oh, that's an insight. That's, I always say, are those groups, PMOs and enterprise architects and release management, if you ask your teams, would they consider them to be enablers of your agility or impediments? What do you think, right? I'm telling you, they should be enablers and this is their new mindset that we need to teach them. So anyway, an insight, business cases, they're too waterfall-ish, too bureaucratic. So what we do is, what is an option? Well, it might be several, but one of them might be, let's come up with a one-page business case, a lightweight one-page A4 business case. So what you do is, you don't go into the PMO and say, I'm here to introduce agile, we're not doing that anymore, we're gonna do this. No, that's not what you do. You negotiate with them to say, we have a hypothesis, we believe that replacing that 50-page business case with a one-page is gonna save us a lot of time and money and we actually won't miss that 50-pager. And you know what? Let's try that for three or four projects and if that doesn't work, we can go back to the way we used to do it. That's really important. If they know, you've said in the hypothesis, an experiment, if it doesn't work out, if they know they can go back to what they're comfortable with, they're more likely to give it a try. So that's very important, negotiating the change.  So you prepare for the change, you introduce it, you measure it for a while. If it's good, you keep doing it. Maybe you'll learn that maybe there's another option you should try. So experiment with that. Or maybe you roll it back. That wasn't a good idea. Let's go back to what you were doing before. This is the change management process. So a minimal viable change, a very tiny change that maximizes the value while minimizing the disruption. And you can and should be doing several of these at once. This is not a serial one at a time type of thing. Absolutely. And thank you for that, Scott. So what we do is we take each of those changes and we put them on a combo on board. And everybody can see it. No secrets. Just like everybody else, you can see the stuff the MVCs that are in progress, the ones that have been done now are reviewing them to see whether or not they're working. And ones that we've... Yeah, they're done. It's now being institutionalized. Now let's pull another change in. It's classic lean combo. You don't have too much whip, right? Too much work in progress. But this is how you roll out your MVCs. Thanks, Scott. Now metrics. Metrics is an important part of transformation. I can't remember who I heard saying this. It might have been Scott yesterday, but absolutely, you want... The time to start introducing metrics is not halfway through your transformation. It's day one. It's when things are bad. So start metrics when things are already good. And now this can be demoralized into the teams when we show them, gee, we're failing our sprints every time, and we're capturing that as a metrics. But I always say, you know what, that's okay, because we're learning. And you're going to feel really good when those reds start to turn to greens. So start metrics when things are bad. Don't wait. That's a key lesson learned that I've learned over the years as well. Now, we also... I mean, we have a lot of webinars and discipline agile for the consortium. And we've done webinars on metrics on this lean change method. And when we talk about metrics, you don't want to Google top 10 agile metrics and roll them out. You want to do metrics design. You want to roll out very few metrics. And we actually talk about this in our Lean Governance course as well. It's a one-day course. You want to roll out very few metrics and targeted metrics to measure the progress against the pain in the organization. Every organization is going to have different pains. Throughput, value from IT spend, quality, attrition, morale, every organization is different. So if quality is the perceived problem, then roll out a metric initially to measure improvement in quality. So what you see here is we use a technique called goal question metric. This is just one of the strategies. There are different strategies for metrics. OKRs is another one, objectives, key results. We actually like GQM better, but we're all about choice. But we like it. It works for us. So what you see here is a goal might be to improve delivery dependability. That's a goal. Well, what questions can we ask to help us understand whether or not we're improving our IT deliverability? The question might be, are teams dedicated to actually meeting their commitments? Or are they kind of not focused? Right? OK, that's a good question. How do we measure that? Well, we could say the percentage of planned versus delivered work that was actually delivered. Or percentage of time that the team has to dedicate to pulling work off their own backlog. Maybe they're distracted by management activities or another project. So you can actually measure this. So there's examples of metrics. Now what you see here is that, remember the change canvas I showed you? And in the middle there was a vision with the key things that they wanted to achieve? Well, these metrics map to those so we can tell whether or not we're actually succeeding in our transformation. People often ask us, how do I measure success? This is how you measure. So you see here, improve IT delivery dependability is actually the very first transformation goal. It's a measure against your transformation effort. This is a real example from a client where they've actually put all this stuff together on one whiteboard, very agile and lean and small. But you can see here a mixture of a number of things. I took a picture of this because I thought, well, this is kind of neat. A lot of stuff going on here. Bottom left, what you can see is they were redesigning the work spaces for the team. In the middle is a strategy board to talk about their key objectives and key categories. Next to it, the first metrics that they're rolling out. And then the moving away, moving from is the, I showed you an example of that in a previous slide. For this company, I remember there was, I was, this is in the coach's room, the internal product owner I told you about and I was in there having a meeting with him and there was a board of directors meeting that day and they were doing a walk around to the floor. It's a software product company. The board is walking around the floor and they walk into our office and they say, what's going on here? We tell them what we're doing and I remember the board member going up and he looked at these and he was asking us questions about our progress against each of these objectives. It's not really hard to understand, right? But there's a good example of information radiators, transparency being held accountable for what you're doing. Okay, I'm just about done. I'm going to pass it over to Scott in a second. This is a journey. It's not a destination. Transformations, the hard stuff, last typically a few years but then it morphs into a continuous improvement journey which goes on and on and on. So you do the hard transformation stuff but understand that it's going, continuous improvement is going to continue. Now inside this one, how do you organize all this guidance? We organize it into things called goal diagrams or process blades and here you're looking at the continuous improvement process blade and the rectangles are things that you need to think about that help you with your continuous improvement and a couple I want to talk about right now are COPs and COEs and we don't have time to talk about all the details. I want to highlight some things here. People get mixed up between the difference of a COE and a COP. A center of excellence is like your transformation team. They're there typically for a shorter period of time, full-time staff with people as part of an initiative to do your transformation. Hopefully you get some coaching involved to help you out with your COE. A COP on the other hand is more of a longer term construct what Spotify calls guilds. I happen to like that term. I think it sounds like a medieval guild where it's all about the craft and staffed by practitioners and they learn from each other sort of longer term. So there's a difference between COEs and COPs. This is an actual picture of one of our clients and I took a picture of it because I thought it was kind of cool that in a certain area of the floor we had these labels, there's a typo here, just say disciplined agile and continuous improvement. So they put the COE and COPs together into one group and then another group is about the DevOps, integration, CI, CD and how DA can help you with that. So really nice to see this visual recognition of these groups in our customers. So I'm going to do this slide now, toss it back to Scott. Invest in coaching. You know, coaching are accelerators on your journey. They can get you from A to B much quicker than trying to figure it out yourself. Trying to figure out yourself is a time-consuming and very costly prospect. Okay, so coaching can really accelerate your journey. You're going to have different kinds of coaches, technical coaches, you know, scrum kind of coaches, team coaches, enterprise coaches and make sure that they're coaching not just the teams but the other areas in your organization. And with that, I think I'll toss it back to Scott. Yeah, thank you. So one of the themes that is a tad dysfunctional in my opinion in the Azure community is that it's all about mindset. And certainly mindset is important, you know, don't get me wrong.  And this, I think, we need the skills and I think some of the speakers that Dave Farley was getting at that yesterday, we need the technical skills to do the job as well. We need to know what we're doing. So it's not just about mindset. It's not, you know, mindset is absolutely critical but we also need the skillset as well. So don't buy into some of the easy, you know, touchy, feely fixes stuff. It's all critical but it's not the full picture. So we're firm believers in looking at the full picture. You know, for those of you who attended yesterday's talk, we saw this and when you adopt these prescriptive methods, these prescriptive frameworks, there is value. Like, you know, we saw some industry stats, 7% to 12% and good stuff like that. There's value there without a doubt. That's a good improvement. So when you're successful at adopting these methods, things get better. But like I was saying earlier, with all these DevOps case studies, they're all basically the same. The message is the same. We want to take this experimental approach. We want to try new ideas, see if they work for us. Because every team is different. Everybody, every person is different. Every team is different. Every organization is different. And just because a strategy or practice works well for somebody else, doesn't mean it's going to work for you. You need to try it out, see what works for you, adopt the good stuff, abandon the bad stuff, measure, Mark was getting at this earlier with the lean change management stuff. So the basic message here is we want to be constantly iterating, we want to be constantly experimenting and adopting new ways of working to see what works for us. And the Disponential Toolkit provides some guidance. You don't have to reinvent the wheel. We could have the humility to recognize that other people, other teams have dealt with the same challenges that we currently face. So we could leverage their learnings. We could leverage these other strategies that are proven in practice. And like Mark was saying earlier, by using the toolkit, we can actually identify likely strategies that will work for us in the context that we face. Because we have options. There are no such things as best practices. There's always multiple ways to do things. So let's choose, my philosophy, our philosophy is do the best you can in the situation that you face and always try to get better. So this is what we're aiming at. So what we can do is with a little bit of lightweight guidance, we can achieve better results over time. So instead of trying to reinvent the wheel like we see in figuring it out on your own in the dash line, which works well, but it's a little bit slower and expensive, we can speed things up by making better decisions at the very beginning and running experiments that are more likely to succeed. So we can succeed. Instead of just failing fast, which is a good strategy, we can succeed earlier, which is what we're getting at. So a little more positive spin and we can do this. So if you are in method prison right now, like Ivor Yakubin likes to say, if you are following a process you've either chosen to adopt a method or adopt a framework or it's been forced upon you, okay, fine, that is what it is, but we can work our way out of method prison and get on this true improvement path that we've been talking about, exactly like we've been hearing from all these DevOps organizations. So we can get out of jail free or get out of jail with a little bit of work, I should say. So anyway, so I'll hand it off to Mark again for a little few thoughts. I'm not just for just about our time, so I'll keep it quick here. These are real life examples from some of our clients. Simplify your process, get your stuff out of Microsoft project, get it on walls. Now, I know you all know that. I know that's obvious in the agile world, but this is an example of an MVC, right? You go in and say, hey, let's stop doing the Microsoft project stuff. I know it's agile basics, but all the stuff needs to be prioritized. So there's an example of an MVC. Another one is simplify the process. Get away from long front planning. Replace it with agile, what we call inception. You might think of it as sprint zero. We take a little bit more rigorous approach to sprint zero, by the way, and we call it inception. So this is a real life example of an inception workshop with some story mapping going on, visualizing or exploring the architecture on the left-hand side. And then another MVC might be we need to change workspaces. Let's design new workspaces. True story here. Started with drawings. Went to a furniture company. Prototyped work area on the bottom right. You see that the whole, they've redesigned the entire space. By the way, the manager's offices have been moved into the middle of the floor so that the developers can get the windows. Yeah, so just wrapping up. Yeah, and another common theme at the conference is we really need leaders, not just managers. So today's managers I would hope or everybody I hope would move into a, become more leadership focused. And we should inspire the change. We should be the change that we want to be. So some of the critical ideas you've heard here, you have a product order champion for your transformation and also have a succession plan for your champion. Because this is a multi-year journey. You can't count on the champion and the product owner to be around all that time. They leave, they move on to other things. You can't count on somebody else to take over and to fill in if they decide to move on. Constant communication, absolutely critical. Have these visible walls, these visible work boards. Because he's saying here's what we're trying to achieve, here's what we're doing, here's what's working well, here's what's not working well. Have this constant drum beat. And I find that annoying actually, having to do it, but you've got to continue to say here's what we're doing, here's where we are and just have this regular drum beat with the same message. So you want to repeat yourself constantly on this. Definitely get some good coaching. We're obviously biased because we do coaching, but you need coaches. You need people to help you. Both at the team level, at the enterprise level, at the specialized level as well. So coaching the finance or the procurement people is a different thing than coaching software development people. Coaching the data management folks is definitely a different thing too. And you've got to have a background because if you don't know how to do what you're coaching in, your advice is going to be questionable at best. So this I think is a challenge the Agile community faces right now around the quality of our coaches and not having the background. It was interesting yesterday the presentation started off with how many people here are coaches, how many people raised their hand, and then the next question was how many people are experts in Agile and only three or four people raised their hand? I'll just leave it at that. There's this question here. So anyway, time for a minute or so for questions, maybe one or two questions? One or two? Probably one question. Two minutes. Okay, question. Good question. How do we measure the readiness of the client for a transformation? That's why we start with an assessment. We're going to go out and talk to stakeholders at all levels. Team level, middle management, executives, and help them understand if they have the right mindset to address the change. You know, Scott, one of the antipatterns is waiting until there's a crisis to do with the transformation. But I can tell you that often that's what starts the transformation. We get the call to say, Mark, help us. We're not competitive anymore. And then we start... We're willing to walk away from a transformation if they're not willing to do some of the harder things. For sure. A framework? Yeah, we talk about it in our executive guide. You can find it on Amazon. Standard is probably the wrong word. For example, we've got several flavors of doing the assessments. Like a workshoppy type of thing versus an interview type of thing. Because you've got to judge the existing culture of the organization. We'll guide the decisions in what type of assessment will work well for them. And as well, what are they willing to actually work towards? We are here for the week. So don't be shy about coming up to us. Look for the blue shirt or the white shirt with this ponage on it. Be happy to answer any questions that you have over a team. I'll be blue for every other day than today. One more question, maybe, quickly. Everybody has to become agile. It is not only the delivery teams. So when new management approaches to you... So that happens in the stage level or everything is addressed at one point. It takes a few years, I understand. But how do you plan for it as a coach? I mean, how do you suggest them? Some of his catches catch can. But you've got to realize that if we're helping a team here and they interact with five other teams to get the job done, then part of the strategy has got to be these five other teams have to at least become agile enough to allow this team here to succeed at becoming agile. Or they have to be willing to get out of the way. So that's the logic. You've got to sort of eat the elephant one bite at a time. My key point would be, yes, exactly. It's a big elephant. And you need to understand which are the highest pain points and get low-hanging fruit. Go after the biggest pains in the organization and take a lean approach. Don't take a waterfall. Try to design the entire transformation up front.  And you will find after a couple of years the organization is a completely different organization than it was before you started. It's one of the reasons that we're so passionate about what we do is by the time we leave everybody's happier. There's a gentleman over here that worked with me in the United States at a large pizza company and one of the things I helped them do was get rid of time sheets and time tracking. Anybody here love time tracking? No, no more. They don't need to do them anymore. They're just increasing the joy of both finance and the teams. That's just one simple example. So it can be a lot of fun. So thank you very much. We will be around. We're easy to find online if you can't find us when we're here. Thank you.


Okay, so when they asked me if you want to do the last talk, of course, it puts a little bit of pressure, so hopefully you come out of this with a couple things that are interesting to you. The other thing is that Evan had also submitted a talk about the future of serverless, so it was important for us not to overlap. And I think we don't overlap. And actually, his talk, I think, is probably better than this, but I hope this will leave you with at least an inspiration. I hope, at least one point. But if you want to understand the details, the technology, and so on, I really encourage you to re-watch Evan's talk at the beginning. It was the first talk of the conference. So let's get to it. Obviously, let's think Red Hat. It is part of IBM, but we really treat it as separate companies. I still don't have a way to look for Nina's email. I don't know if that's an indication of something else, but it's definitely separate companies. But take them. So I'm not thinking IBM. I'm thinking Red Hat. So the statement here is the future is serverless. And I think a lot of you here are probably bought into this, because otherwise, why would you be here? Or at least you're trying to learn. But I guess maybe the question is, is it the future of cloud computing? And then the other thing, more important, which I'm not asking, but I hope I answer, is why? Like, when you talk to a customer, why do you think serverless is the key? Like, why is it the future? And I think that's the point that I'm going to try to answer. I'm making a lot of assumptions. Feel free to ask me some questions at the end, and also complain or challenge me. So with that, let me ask you a question. Since I'm a photographer, I take it very seriously. This is a real photo of San Francisco. And there are three obvious landmarks of San Francisco. This is Coyt Tower. This is the famous Trans-America pyramid. And then this is a new building. Lots of nicknames, but you can call it the Salesforce Tower. So question to you if you've been to San Francisco, or you live in San Francisco. Let me kill this. Is which one of these three things are taller? Anybody? Okay, so somebody says it's the Trans-America. Anybody else? All right, so Moo says Salesforce. So the reality is that the Salesforce Tower is 1,000 feet. Trans-America is only 850 feet, and you can see Coyt Tower is 210. And this is a real photo. I did not fake this. And the reason this appears like this, if you're into photography, you understand there's a little bit of compression, there's a little bit of perspective. I happen to be in one spot in San Francisco where all three of these things appear almost next to each other. And with a long lens, I can make it look like that. And I can actually, if you know a little bit, you can actually change also the composition. And the reason I wanted to show this is because a lot of time it's about perspective. Always, always about perspective. So keep that in mind. Here's another picture. It's not gonna help. It's not gonna make some of my friends happy. I just saw my friend Nima on the back just to join. But the reality is when you leave instances running, and not just on AWS, by the way, in any cloud, you're spending a lot of money. I don't know if you're gonna be poor like him, but you're definitely spending money. The next thing is that I did a search on Google before coming here. What is the impact of energy consumption in the environment? And would reducing energy consumption help? And just trust me, it is definitely true. If you can reduce your energy consumption, it helps. Now, obviously if you reduce your energy consumption, that's using less carbon fuel, it's even better and so on. But overall, as a people, as a species, as a planet, if we reduce energy consumption, it should help. So keep also that in mind. So let's jump in. So the talk is structured in three parts, but with two parts each, so six. Motivation with some historical context, the vision and use cases, and then challenges and solutions. But again, as I mentioned, we can't really cover everything just because it's 20 minutes. But also I think people like Evan did a way better job than me of covering some of those aspects. So I tried to only cover some parts that he did not cover. Sorry. I started with a picture. This is a picture actually not from the IBM building where I work. And of course, if you understand the colors, then you understand why I put this picture. The other thing is this was taken with an iPhone 14. So you don't really need fancy cameras to take decent pictures. So the motivation I think is cloud computing is at the center of everything we're doing. So mobile edge, we saw lots of really good talks about this. But cloud computing right now is actually growing at 15%. That's probably part of why we're here, since Kubernetes is sort of the underpinning of a lot of cloud computing in these communities. And IT spending is over 50% now on cloud computing. So businesses like Amazon are growing like crazy and of course other companies as well. So that's important. But here's another part that's important too, is that it's consuming about 1 to 1.5% of global energy. And that is real. It's actually going to only grow. This quote is actually a little bit older because you don't compute these things until after two or three years. So it's going to keep growing. So if we continue at this pace, what's the impact on the environment and also what could we do? And I think for me, one of the things that is important is to put things in the historical context of where things are. If you look at evolution of computing from mainframe to where we are now, it's always been about trying to reduce cost, about increasing capacity and increasing computation, but at the same time reducing cost. So what can we do in some ways to continue this trend and what are all the new trends as well? So there's a picture of the Valley of the Gods. No, not Valley of the Gods. Exactly. So it's in Colorado Spring beautiful obviously and gives you this view of where things are. So let's try to paint a vision. So I already sold you or you're here because you understand serverless. And certainly with Knative as one example built on top of Kubernetes. But all of this while being true and we are here today, we're still not mainstream. We're not yet there. Meaning that probably most of the applications that are running today are not necessarily using Knative. If they're using Kubernetes, they use Kubernetes straight up. So what's the challenge? What could we motivate them on? What could we do? I don't have all the answers, but I think it's important for us to ask this question. And actually towards the end, I will also have a slide on the threats to everything I'm saying where I say potentially everything is not true at all. So let's be careful. So what could we do? Can we actually get to a point where we're more mainstream? I think the first thing is managing costs. I think anybody that says this is not true, let me just pull my BS card.  Very few people will not want to spend less money. So it's very important that we sell Serverless that way, in my opinion. And the reason we can do this is because Serverless actually can potentially help when it comes to costs, both for the users and also for the cloud providers. Because as a cloud user, you're only paying for what you're using. Ideally, it's optimal. Meaning that you use only this amount of resource that's on me what you're paying for. The other important thing, obviously, is that as a cloud provider, you don't have to provision lots of resources. You don't need to over provision. You can provision just enough to meet your current users' demand. Now, obviously, it requires you to do something fancy like defragmentation like we're doing here. So if you look at this picture where you're running, let's say this is a rack with lots of nodes and the black nodes are the nodes that are hot, meaning that they actually have things running. The white nodes are kind of cold. Well, an optimal solution, like an optimal allocation would be this one, where only the black nodes are running on machines. Every other machines are not being used. So what you really need is to over commit only to provide a statistical guarantee. So you don't really need all those extra resources running. You only need the minimum. Now, of course, it requires you to do some work, but that's what it is. Now, you could say, well, yeah, but how much am I paying when I keep stuff running? A lot. I mean, there is... I don't have the slide here, but there is a slide where I show the amount of energy costs that cloud is costing, and it keeps on increasing. So when you're managing a cloud, that's the most amount of energy and cost that you're spending. So as a cloud provider, you'll save money. As a user, ideally, it will be optimal. Sorry. What are the environmental impact? For me, this is maybe the thing that I would ask you all to be thinking about is the fact that by simply reducing the amount of energy that cloud computing are using, we can actually help the environment. We can achieve to a point... We can run our applications and feeling that it's saving us money, but it's using less resources, which in the end costs less. And I didn't put this here, but there is a series of efforts around Kubernetes to be more sustainable, and that's exactly the idea, is to essentially get to a point where we're not over-provisioning for things that we don't need. We're not over-using energy. We're just using what we need. And I think serverless is perfectly placed to essentially drive this mission even more. This is the slide that shows how much energy we're spending over time in cloud, and you can see it keeps on increasing. And this is in, I think, terorots per hour. So what are some new use cases that we could move serverless towards? Because if we got to make it mainstream, it has to be beyond the simple request response, because right now we're not really doing those things with serverless. I mean, we're selling it, but people are not necessarily using it. So there are two use cases I want to highlight. The first one is data and AI, and I think one of the previous talks talked about how they're using data and AI in Kubeflow, KF serving, to essentially achieve, you know, same model learning, but in a sense in a serverless fashion. The second one is quantum computing. So, you know, we won't go into too much detail, but basically suffice it to say that one of the things that we're doing, for instance, at IBM, it's going to sound a little bit like a sales pitch, but there is a effort towards having quantum serverless. And the simplest way to think of it is these computers, so that's a picture of one, they use a lot of energy, but they solve problems, some problems, orders of magnitude faster than any classical computer. But in order for you to use them, you have to prepare it. So you have to set it up, you have to create the circuit that is actually going to be executing on the quantum computer. And all of that can be done in serverless fashion, and that's what we mean by serverless, quantum serverless. So here's a better picture of this. And basically you could think of it as as you run your stuff on a quantum computer, the things that we're going to do, like, for instance, creating the circuit from out of multiple pieces, putting it together, dealing with error correction. All of this will be done in a serverless fashion in classical computers. And this is the quote in the Journal of Applied Physics. So if you're interested in this paper, let me know, I have the PDF I can share with you. What are the challenges? So this is a picture of a bridge called Bigsy Bridge in Big Sur. And the reason I show it is because it's not only beautiful, but think about the engineering challenge to build this. And I believe they built this in the 1950s. So we can do it. First thing is optimization, because if you're going to build stuff with serverless, it has to appear like it's running just as fast. And one of the problems that we have right now is that the cold start is orders of magnitude more than what it should be. It should be in the 10 milliseconds, it's in the 10 of milliseconds. So my colleague Paul Schweiger on the back has a paper or a blog where he talks about where the cold start is being spent. So we've got to be able to reduce this. And what can we do? Another part is the design. How do you take your application and design it for serverless? Because when you do this, then you're able to better achieve the benefits of serverless. And the details of this, I think we talked about, but basically it's about understanding how to use the function work and Lens talked about how to decompose your application, how to exchange events between them and potentially how you do workflows. Security is also another aspect, because now that you have multiple pieces, how do you secure this and keeping it secure? And we have work on this that's going on. I'm moving a little bit fast, because I don't have a lot of time left. This final picture is can we achieve this Nirvana? Can we get to a point where actually serverless is helping us, but can we get to that point? This is a picture in San Francisco of the painted ladies, I think, but nice view of the city, and obviously everybody's in love, right? And some of the things that we're doing to achieve, to address the problems that we talked about specifically, are things like, for instance, freezing containers, faster probing in the underlying Kubernetes layers, things like, for instance, security guard, a new project that got started to essentially help security at runtime. Trying to get to better standards, so I'm part of this open cost group, where we're essentially trying to make sure that costing across cloud can be compared. The Kubernetes sustainability efforts are also part of it. And then in terms of allowing a flow of these different serverless components to make it a little bit easier, things like Tecton obviously expanded and then serverless workflow. But what are the threats of agility? So Nima just walked in and he sent me this tweet, I think a few weeks ago, a few days ago, sorry, by this guy that essentially says, I spoke to a team yesterday that essentially is moving away from serverless. And the reason he mentioned, and I kind of summarized part of it here, is that you build a monolith, a monolith is easier to build, easier to test, easier to manage, easier to evolve, and easier to secure. Because we know how to do it, everybody knows how to do it, it's a big pile of code, and we can do it. And of course, Kubernetes is also hard, which makes Knative and serverless even harder. And developer's time is expensive, but we can just waste resources. And I hope you believe that these threats, while real, I don't think any of them are actually a sign of fundamental issues with the way we're doing serverless. It's more of reality of teams, reality of what you have as your background before, reality of potentially the state of your organization in terms of the maturity level of your organization. So none of it is actually threats that should prevent you from trying serverless. But they are real, and they exist, and you need to be aware of them. So just to summarize, I want you to leave here thinking that when you sell serverless or you talk serverless to your team members, to your management team, that there is really two main advantages that we have to be clear on, is that it will achieve better cost, both the provider will be able to reduce, and then as a user, you'll be able to use those resources cheaper. And it's potentially very good for the environment. And why would you not want that? And why would you not want to advertise that as well? But there are lots of challenges, but we can solve those challenges, and we're actually working on those. So with that, let me mention that the goal is to achieve a serverless first world, right? How do we get there? And the last thing I want to do is to show you three pictures, because in case you're not believing in the impact to the environment, and how important it is to us, look at three pictures from the Bay Area, okay? This is one, this is another one, and this is another one. The reason I show this is because, obviously, there is an orange U in the Bay Area that happens at night. But one of these three pictures is not mine, and one of these three pictures is when we had this massive fire in 2020. And it's this one. You would think, but it's real. It's happening, and it's impacting all of us. So even us as computer scientists, we should be working towards helping the environment. So I really think that as a serverless community, we need to be thinking of not only costs, but also how do we help the environment? So with that, I want to thank you, and thank the community, and then Red Hat, and let you know how to reach me. Thank you.


Welcome to our Yellowstone as presented by Montana State University Libraries Acoustic Atlas. The Acoustic Atlas is MSU Libraries digital audio archive of animal and environmental sounds from Montana, the Greater Yellowstone Ecosystem, and the American West. These recordings and many others can be accessed at acousticatalyst.org. The first reporting we're going to hear is the sound of a pika, a small animal that lives in Yellowstone's high alpine region. The next recording we'll hear are the sounds of spadefoot, toads, and boreal chorus frogs. The next recording is the sound of Vixen Geyser erupting in Norse Geyser Basin. The next recording is the sound of San Hill Cranes as they fly south on their migration. The following recording you may recognize as Yellowstone's famous gray walls. The next recording contains the sounds of elk, canada geese, looms, coots, and red squirrels. Listen now to the sounds of the iconic American Bison. Familiar sound in September is the bugling of bull elk in Yellowstone. The last sound in our presentation is that of the meeting of two grizzly bears. Remember, every natural environment, every ecosystem has its voice. acousticatalyst.org. Thank you.


What boys if you're new here shout the easy not too easy Shout of zaps shout of the new followers if you are new here, please hit the follow button. We call this the 360 no scope


Welcome to the anxious morning every weekday morning will take a few minutes to go over important lessons that you can use in your anxiety recovery journey The anxious morning brings you support education inspiration encouragement and empowerment Read or listen quietly on your own time free of the endless noisy scroll of social media Use the information to help you along the path to recovery from panic disorder Agoraphobia and other anxiety problems for more visit us at the anxious morning calm Does the ultimate panic attack exist? Are you afraid that it will break or kill you? If you struggle with panic attacks or panic disorder, you may be gripped by a very common fear You may be afraid that one day you will have a panic attack so big so intense so severe that there is permanent impact The most common variations on this theme revolve around panic or in high anxiety that simply never ends or that trigger a Psychotic break or slide into insanity This is the ultimate panic attack. Do you fear this ultimate panic attack? Are you afraid that you will wind up in a state of insanity or permanent torture? So many members of our community harbor this fear So many live each day in a state of hypervigilance always scanning the horizon for the approaching threat Bracing holding on knowing that surrender and acceptance is the way But unable to bring themselves to truly let go for fear that they will be overtaken once and for all by the ultimate panic attack Well, let me give you some good news No such panic attack exists. It never has There is no such thing as permanent panic and no direct path from a panic attack to a state of insanity or psychosis I am aware that at its peak panic will often have you believing that you are mere nanoseconds from snapping and completely losing control of your Mind and or body. I know how that feels. It's quite terrifying However, that fear does not have any connection to any real potential outcome Ultimate panic that never ends or drives one to insanity simply does not exist No matter how much you fear that it does or feel that you are inches away from it I can tell you this a thousand times over the next four days You may believe me and feel relieved temporarily But as it is so often said in this community when the panic hits everything I know goes out the window The minute you sense signs or signals of rising anxiety, you will forget what I told you and your fear will return So how can you finally believe once and for all that all your fear of the ultimate panic attack is unfounded? Sadly you will believe this once you let the ultimate panic come and get you then experience repeated outcomes where it does not Let go allow the worst outcome then it never happens and then repeat Over time you will finally believe that there was no such thing as the ultimate panic attack And you will lose the belief and fear of permanent torture or insanity Right now.  I knew he was gonna say that Well, of course I was but that is always the way. I'm guessing that the next question in your head is Okay, Drew, but how do I let go surrender and accept the worst outcome? Well, that is what the anxious morning is all about as we go down this path together There will be many lessons on many different topics that ultimately all converge at how How is a short question with a very long answer? Long enough and complex enough that we'll do our best to answer it with at least 259 more short trips lessons essays thoughts and questions for us to read and ponder together in 2022 Tomorrow we'll look at why the morning is full of power and promise regardless of what your anxiety is telling you Now if you like the podcast and you'd like to have the podcast and full text delivered into your email every morning Visit us at the anxious morning dot email And you can find all the rest of my content including my social media feeds at the anxious truth calm