 Hello everyone. Welcome to the session No Frameworks. How can we take agile back by Scott Ambler? Without any further ado, I will like Scott to take it away. So I'm Scott Ambler. I'm the co-creator of the Dispensational Toolkit. I'm going to talk a little bit about that today. I'm also the thought leader behind agile modeling and agile data. So I've worked in the rational unified process, in object-oriented software patterns. So I've been working and have either worked with or helped to create frameworks for close to 25 years. So I know a little bit about the topic and I'm going to share some ideas with you. So I'm going to start by talking about what a framework is, and then I'm going to explore what some of the challenges are. Then I'm going to actually talk about what really works, and I think you're going to find that very interesting. Then I'll talk a little bit about how we can take agile back from the framework folks. So what's a framework? So there's many possible definitions. I like to take a look at frameworks from two points of view, a prescriptive framework that describes in detail what to do, and usually has one way of working. Then of course, there's flexible frameworks as well. One of the challenges that I see is that many of the frameworks present themselves as flexible, and in some ways that they are, but they don't really tell you how to actually flex. It's a lot of marketing rhetoric. So they tend to be prescriptive, but they claim to be flexible. We'll explore some of the implications of that in a few minutes. So what are some of the challenges that we see in practice with frameworks? So when I talk about frameworks, I'm talking of things like Scrum and Safe and Less and others, Nexus, Scrum at scale, and they're all good. They all have some value. Please don't get me wrong. I'll have some value, but they also have some challenges. So let's focus on the challenges begin with. So frameworks tend to define rules and belief systems, but what happens if those rules aren't applicable? So what happens when you adopt a framework that has a mindset, has an approach that doesn't really fit for your situation? And or maybe the framework is a good fit for you now, but then your situation changes. So for example, last spring, we all went through some pretty major changes when COVID hit, and it was interesting that we shifted from a lot of agile coaches telling us that you can't do agile unless you're co-located and you certainly can't do agile remotely, and now pretty much everybody's doing agile remotely. So reality hits sometimes. So this is some of the challenges with frameworks is that many of the frameworks left it up to you to figure this remote stuff out. The frameworks solve a specific problem. So Scrum solves a specific problem, Safe solves a specific problem, which is great. But if you don't actually have that problem, then even though the framework might be really good, it just isn't very good for you. So for example, in this picture, we see a hammer, hammers solve specific problems. But if I have to fix a glass, so for example, I have a crack in the windshield of my car right now, a hammer is not going to help me fix that. It might help me knock the broken glass out, but it certainly won't fix the real problem. And the real question is what happens after you solve the problem? So once you successfully adopt Scrum or successfully adopt Safe, you solve the problem. Where do you go from there? So the frameworks box you in. The language of the framework limits your ability to discover other ideas. This is a serious problem with Scrum, actually. Even though the Scrum terminology is interesting, it puts you in a certain mindset. And then if you only know Scrum, then it becomes very difficult for you to find techniques that are outside of Scrum or that other Scrum people aren't talking about. I ran into a team suffering from this very problem a few days ago and they were asking me, so how do you, we're solving, we've got this problem that we're Scrum team, we've got this problem. And what do we do? And I said, why the heck did you Google it? There's probably hundreds if not thousands of articles about how I saw that problem. I said, we did, but we couldn't find anything. I said, really? Because I typed away and suddenly up comes all these articles and oh, we never thought to look on that term. Yeah, that's because it's not a Scrum term. So this is the challenge, the language is limiting. And sometimes the frameworks present everything they do is a best practice. This is the one official way of doing things. But what happens if the best practices really aren't best? One of the things that I do is I analyze practices and I don't believe in the term best practice at all. I have never actually found a best practice. I've been looking for over 30 years, I've never found one because all practices have advantages and disadvantages. They work well in some situations and not so well in others. So you really need to think, adopt the right practice in the right situation. So these best practices, they might be pretty good but they might not be best for your situation and they might not be best at all. But they're often pitched as being best because that might be the best that they want to sell you. And sometimes the frameworks are oversold. We hear lots of interesting claims about how much better things will be if you can only adopt a certain framework. But what happens if your team is already pretty good? I've seen some teams literally become 10 times more productive by adopting when they made some changes. It's not because they adopted a certain framework, it's just because they changed and they were doing so poorly that anything would have helped them. So we need to be realistic. And I've been in other situations where we've achieved small gains by adopting a certain framework and that's okay. But the reason why is because the team was already doing pretty well and the framework solved a few problems that the team had. And what do you do when your problems really aren't so easy to solve and that you really do need to rethink the way that you're working? So the flexible frameworks require to use judgment and to make decisions, which is probably pretty good. But what do you do when you don't know what your options are? That team was talking about a few minutes ago when they didn't know that there was existing solutions to the problem they had and they didn't even know how to find them. It's pretty hard when you, if you can't find these solutions. And then how do you compare the options? Like, even if you do know what to look for and find a bunch of ideas, how do you compare them? So the fundamental challenges, these frameworks aren't magic. They have some great ideas. Please don't get me wrong. They've got some great ideas in them, but they're not magic. You're still gonna have to do some hard work. And we all run into these problems that we might wanna adopt a certain framework because it makes sense and because it could possibly help. But then the rest of the organization and particularly our leadership isn't ready. Sometimes our staff isn't sufficiently skilled. So we will adopt a straightforward framework, but for a programming team and we don't have skills in automated regression testing, then we're really gonna struggle for a while. So a fundamental question that we should be asking ourselves is how effective are frameworks in practice? So the people who produce frameworks and who sell them to you and market them to you have claims. There's case studies that tell you how wonderful they are and they'll make claims and you'll hear claims along the lines that you can do twice to the amount of work in half the time. And these are wonderful claims, but are they actually true in practice? And the observation I wanna make is that you can't trust the people that are trying to sell you something and you need to go elsewhere. You'll get third-party advice. So the question is, well, where can we go? So let's make an assumption. So let's assume that you're adopting a framework, a method or a framework, whatever terminology you wanna use and let's assume you do it well. Let's assume you're actually successful, what actually happens? So these sorts of adoptions follow what's known as the S-curve. So at the very beginning you adopt scrum, you adopt safe, you adopt less. So you have to get some training and you get some coaching and your effectiveness goes down for a while because you're learning. This is normal, this is a normal thing. Your effectiveness goes down for a bit of time, but then you get your act together and you think start to get better and you improve and things get better than they were before. But then the framework solves the problem. So earlier I was talking about how a framework will address a specific type of problem. So once you solve that problem through the successful adoption of a framework, it doesn't really have much more to help you with, right? There's a lot of hand-waving, a lot of claims get made and it usually boils down to hire some expensive coaches to take you further. But for the most part, they have nothing to say, right? Other than, yes, of course it's possible. It's the art of the possible. I'm sure you've heard that. So the question becomes now, how on average, where's this peak? How much better did we get? Because we're gonna assume things worked out well that things get better and that's a fair assumption. So like I say, we can't trust the purveyors, the frameworks, who can we trust? Well, there's a gentleman by the name of Dr. Don Riefer and he earned his PhD studying the effectiveness of Agile and he's made a business, turned it into a business. He earned his PhD a few years ago now and he's turned it into a business where he sells the research and he consults but the interesting thing, the important thing about Dr. Riefer is he's not wedded to any of these methods. So he's not a safe guy, he's not a less guy, he's not a dispensable guy, not a scrum guy. He's a researcher and he's looked at a lot of teams around the world. The state is a bit at a date, his work has actually, I think he's over 2,000 teams now but what's interesting is that on average and when some organizations do better and some organizations do worse but on average he's seen improvements along these lines. It's still positive, it's still good but it's nowhere near what some of the claims are. So we need to take this with a grain of salt. So yes, adopting a framework can help, on average it does help but perhaps nowhere near as much has been promised unless of course you're really messed up and then yes, you're probably gonna see greater improvements than if you were doing a reason but well. So what works in practice? So I'm a firm believer in looking at the successful organizations and asking the question, who's doing really well? Who do we admire, what companies do we admire? And I work with executives and I run this exercise with executives sometimes where I basically ask them to identify your competitors and identify the firms that you currently compete against and the firms that you think might be getting into your marketplace. So we get stickies and we write up a bunch of stickies and we put them on the wall. And then depending on the number of executives in the room there could be 40, 50, 60, sometimes even 70 or 80 stickies on the wall after five minutes of brainstorming. Then I go to them and I say, okay fine, now what I want you to do is I want you to arrange these stickies into two categories. The first category is the organizations that you're not worried about competing against. The organizations that don't scare you. The second category is what organizations keep you up at night? Who really worries you? Who are you afraid of competing against? Who do you think is gonna outcompete you basically? So they move the stickies around. And then we look at the wall and then I ask the question. So of these two categories, which groups do you think are adopting agile frameworks and which groups do you think take responsibility for their own process? And it's interesting, the organizations that they're afraid to compete against, which is usually the Amazons, the Googles, the eBay's of the world, or the FinTechs for the financial organizations. They're the ones that have figured out how to do their own, they own their process. They evolve their process and they do continuous improvement over time. The organizations they're typically not worried about almost always they're traditional competitors, which look a lot like them are almost always the ones they believe are adopting frameworks. So my advice would be, let's adopt what the Apex Predators are doing, these, the Googles and the Amazons of the world. And what they do is they follow a link technique called Kaizen, they do continuous improvement. And the way this method works, this strategy works, is shown here. And some people will do, call this UDA or PDCA. But the idea is that they have an issue, they have some sort of problem or they have something they want to improve. Then they identify, well, okay, so how can we potentially improve this problem? They also identify, how are we gonna measure whether or not this worked for us? Then they try out one or more potential new ways of working. And then, and they give it enough time to potentially succeed or to fail. So after a few days, a few weeks, a few months, whatever's a reasonable amount of time for that technique, then they assess the effectiveness. And if it worked out well, they adopt it. If it didn't work out well, they abandoned it. And then if they're polite, and this is sort of my addition, they share their learnings with others. They share at least with the rest of the organization. And then of course, they rinse and repeat. They keep doing this. So they improve in small steps. This is a total quality management technique from at least the 1980s. And it's called Kaizen, improving in small steps. Many of you are probably familiar with it. And if you read anything about the Amazon case studies, the Google case studies, or eBay, this is the technique that they followed to get good. And they've been doing this for so long, this is why they're so good. Because they've been on this path for 15, 20 years now. And they improve in small steps over time. And then over time, they just get really, really scary. This is why they're so hyper competitive. So when you take this sort of an approach, you get a process improvement curve that looks like this. You just keep improving. Now to be fair, this is a high level overview. This line is really dashed, right? Because sometimes your experiments fail, so your effectiveness goes down for a bit, but then you go back up again. But over time, your overall effectiveness on average improves. And it keeps on improving. This is what we're seeing in Amazon. This is what we're seeing in Google and many other organizations that have been doing this. They just keep getting better one small step at a time. So can we do better or can we do a lot better? And a couple of interesting observations here is the Amazons and eBay's of the world are on the leading edge. So they often have, they really do create new techniques and they figure things out. I'm sure you've been to conferences and you've read articles and you've heard about all these really awesome techniques and these awesome things that they're doing. The DevOps community, for example, has a lot of techniques coming out of these firms. So they really are leading the way. Chances are pretty good, that's not your firm. Chances are pretty good, you're reasonably behind and can catch up. So because you're behind, this can in fact be a bit of an advantage because you can leverage the learnings of other organizations. So let's take a look at the guide to continuous improvement again. So where could we improve continuous improvement? So the thing is that third step, when you try out solutions, this is where some of the problem is because the problem is some of your experiments fail. And yes, the consultants will tell you, well, it's not really a failure, we're learning something, so this is good. Well, I'm gonna tell you, I'm gonna be honest with you. For the people paying the bill for these failures, they don't wanna hear this, right? They've heard the word failure and yeah, some things fail, that's fine, but when you fail over and over and over again, suddenly it gets pretty expensive pretty quickly and sometimes people will also tell you, well, we're really failing fast. And to be fair, that's far better than failing slowly, but it's still a failure. So can we do better? So failing fast is definitely fine, way better than failing slowly, but succeeding early is far better than that. So how do we do that? Well, if we look at the second step, if we can get better at identifying a potential new technique to experiment with, if we can identify something that's most likely gonna work for the situation that we face, we will fail less often, we'll succeed more often. So the side effect of that is that we have fewer failures, more successes, and that results in faster and less expensive improvement. So how do we do that? Well, there's two ways. If we have access to an experienced agile coach who has seen these sorts of problems before and can convince you to do the improvement, then that's pretty good. Problem is you might not have access to such coaches and these coaches are actually few and far between. A lot of people out there claiming to be a coach, but they might not have the experience to actually help you solve your problems. They might be really good at working on certain frameworks, but once you get past the framework, you are now in territory where they've never gone before, either. Another approach, which can be combined with coaching, and frankly, a coach with a good knowledge base is a very good thing, is if you have access to a process knowledge base, like Dispen Agile, I'm gonna walk you through an example of this in a minute, then you can actually leverage the learnings of others. Because even though your situation is unique, you are a unique person, your team is unique, you face unique situation. So even though you're unique, the fact is is that other teams before you, more likely thousands of teams before you, have faced similar problems and have solved that problem. So if you can get access to their learnings, if you can get access to the techniques they came up with to solve that problem, then you can also adopt those techniques to solve the problem, hopefully. So where continuous improvement has a improvement curve like this, which is very good, guided continuous improvement has a steeper improvement curve, I should say, because there's fewer failures, more successes leads to faster improvement. It's as simple as that. So let's work through an example. So we have a challenge. And our challenge is we're working on a solution and we brought this solution to market and we understand our existing customers, but we're struggling to attract new customers. So we don't know what features, potential new customers would like. So we're having challenges exploring scope. So when we're exploring scope, and exploring the scope of what you're building, there's a little more to it than just writing up user stories and epics and good stuff like that. So when we're exploring scope, we should be asking basic questions. So how will people use their solution? What information will we collect? What data are we collecting? What processes does it follow? And other questions, how will we interact with it? Are there any, how are we gonna document these requirements? How will we handle changing requirements? So for example, in Scrum, they talk about a product backlog. That's one way of doing it. There's others. There's several other ways that we can manage our evolving requirements and some of which are better than product backlogs. But anyways, I'll just leave that out there for you. So here's our challenge. So we don't understand how new customers could, would want to work with our system. We don't know how to identify features that will attract them to our system, our solution. So the problem is, is we don't know how to explore, we're struggling to explore usage. How will they use our system to get value? So we look at what's called a goal diagram and I'll show you an example of this in a minute. So we've got a problem with exploring usage. So we look at the goal diagram and we realize, well, there's different ways of doing explore usage. We could write up epics or outcomes or personas or stories or other techniques. We have options. Each of these options have advantages. So epics, there's certain advantages to epics and there's certain disadvantages to epics as well. They work well in some situations and not so well in others. And the same thing for these other techniques as well. So chances are pretty good because we're struggling to understand what potential new customers want, we need to, so right now our team is probably writing, it is writing up epics and stories and it's not getting the job done. So we come and we look at this at this list and we realize, hey, there's other techniques here. You know, if I knew something about them, maybe I could adopt them. So if you have an experienced coach, right away the experienced coach is probably gonna tell you, you know, just the fact that we had problems exploring usage, that might clue into the fact that, hey, personas might be the way to go. If they're not experienced with personas because maybe they're merely a scrum coach, then they wouldn't know that. So we would then go and look at this list and, oh, you know, maybe, and if somebody on the team had some greater experience, maybe they'd clue into, oh yeah, personas, I remember personas, we did that years ago and it worked out really well, we should try this. If we have no experience at all with any of these techniques other than the ones we've been trained in, then we would have to go look them up in the toolkit itself. Sometimes, so this is an example of what we call an unordered list. All these techniques are interesting, they all have advantages and disadvantages, but I can't tell you that one technique is better than another. Sometimes, that's not the case, sometimes the techniques are ordered. So for example, when we talk about the level of detail, how much detail should we capture when we write up these requirements? Having a brief overview tends to be, you know, like writing up an index card or writing up something in JIRA tends to be good enough. Having a light specification, so maybe having a screen sketch associated with the user story can be sufficient. Writing of a detailed specification is also an option and then writing no documentation at all is also an option. So when we see lists like this with an arrow beside them, what we're indicating is that the strategy towards the top of the list are generally more effective than the strategies towards the bottom of the list. Now, your mileage may vary and your situation may be strange and require a certain way of working and that's okay, that's your situation. But in general, the strategies towards the top of the list generally better than the others. When there's no arrow, I can't tell you that technique X is better than technique Y. So this is an example of what we call a goal diagram, process goal diagram. So this is a simple map of how do we find out information about exploring scope? So the idea here is that the way you read this is when we explore scope, we have certain intents or certain process decisions that we need to make. So how are we gonna go about exploring usage? How are we gonna go about exploring the domain, the data? How are we gonna go about exploring the process and so on? To the right of each of these issues, each of these intents are options. And we're not saying we've identified all possible options in the known universe, but we are saying that we've identified a pretty darn good list and it's evolving over time. Enough to let you know that you've got choices which right away gets you out of the mindset of many of these frameworks that often only tell you about one or two techniques and present them as best practices. Because once again, there is no such thing as a best practice. All practices are contextual in nature. They might work well for you in some situations and not so well in others. This is why you need to experiment with them to see does this work for me in the situation that I face. And then, so try it out and if it works well, adopt it. If it doesn't work well, don't adopt it. And the only way you can make better decisions is by knowing what the trade-offs are. So the trade-offs are described, so in behind this diagram are tables. So there's descriptions of what these techniques are. There's references to greater detail. If you want to find out all there is to know what UML activity diagrams, there's links. And there's also the trade-offs. So what's the advantage of these techniques? What's the disadvantages? When would you want to use it? When would you not want to use each technique? So that way you can make better decisions because the challenge is your situation is unique. I don't know what your situation is. So me telling you something is the best practice is deceptive because it might be a very good practice but it might not be a good practice for you. You need to make those decisions. So don't stop blindly doing what you're told because that's what the framework tells you is the best practice. And instead, start making choices that are appropriate for your environment. And this is what the scary organizations, the Amazons and the eBay's the world do. They experiment, they learn, they improve and then they rinse and repeat. So how can we take Agile back? How can we dig our way out of framework jail? Oh, I should have also mentioned that earlier when I was showing you the S-curve, Evar Gackenstein coined the term method jail or framework prisons. I just wanted to give him credit where credit is due. So the first thing, my first piece of advice is to respect yourself. Respect is one of the fundamental concepts in Agile and we should respect others but we also need to respect ourselves. We should respect ourselves enough to realize that we can in fact think for ourselves. We can choose to own our own process. We can choose our own way of working and we can learn and improve and get better over time. So first step is to respect ourselves and to realize we are intelligent people, we can make decisions. I would argue that we need to go back to fundamentals. So Agile was originally about describing what works for software development. We can also do the same thing at the organizational level. So as we all know, Agile is far more than just software development and we can go back. We should really be going back to figuring out what works well in the situation that we face. I would also advise to be humble. We can all learn, we can all improve, we can all get better. We should also be humble and recognize that even though we're unique and in a unique situation, other people have solved these problems before, or similar problems before at least, we can learn from that. So if we're humble, we know enough to say, hey, I don't need to reinvent the wheel. I don't need to invent a new technique. When chances are pretty darn good, somebody else has already invented one that's been out there for a while and been proven in practice. So I should at least look at, my first step should be let's go look to see somebody else has already solved this problem and then let's reuse that technique and then adjust it accordingly. But be humble enough to realize that other people have solved whatever challenge you're currently facing, chances are other people have already solved something very similar. We want to be agnostic. We really need to think outside of the box. And earlier I was talking about how the terminology of framework can really limit your thinking. And it's really true. It's interesting. I'll run workshops with people and I will start teaching in new terms and start getting to the question that these terms that they think are normal. But because some of these terms have been around for 25 or 30 years now, we've forgotten the previous terminology. We've forgotten and we've lost effect because of the inappropriate terminology, we have lost just a wealth of information and techniques. Well, we haven't really lost, they're still there but we just can't find them. So by being agnostic by realizing that there's different techniques and different strategies and that we can combine them from different sources, this is absolutely critical to our success. So be very careful about the terminology that you use. And even some of the agnostic stuff is not as agnostic as they think when you start looking at the terminology. But anyways, be as agnostic as you can. And I'm just gonna give you a hint. If you're still using terms like Sprint or Scrum Master, you're not agnostic. But anyways, and those are fine terms, but not agnostic. There are no best practices. Without a doubt, I've mentioned this many times. I'm not gonna go into details on that one but there are no best practices. And like I said, I've been looking for over three decades now. I hope to find a best practice at some point. I find practices, everybody, I run into people pitching best practices all the time. I've never actually seen one that's best but maybe I will one day, who knows? So my advice is start where you are. So what are you currently doing if you're currently a more traditional organization or you're currently doing Scrum or Safe or less? Great, that's what you're doing, good for you. So what are your current wow is? Chances are pretty good, you've plateaued and you don't know why and that's okay. So you can adopt these dispensational guided continuous improvement techniques right away. You can start, you can break out a method gel right now if you choose to. So start where you are. Do the best that you can in the situation that you face and your professionals, I'm sure you're doing that. But then improve in place. Choose to get better at what you're currently doing. Break out a method gel, break out a framework gel. So how do you do this? Observe and try to observe deeply and think. Think about this, observe, recognize the situation that you're in, think about it and then experiment and then of course repeat. And this is what these validated learning techniques, these guided continuous improvement, continuous improvement strategies are all about. We observe, we understand, hey, you've got a problem. We think about how we can potentially solve it and then we experiment with some techniques and observe how well they work and then we keep going. Optimize the whole. Look at the bigger picture. A very serious challenge is over-specialization. We really do need to look at the bigger picture and look beyond the team. One of the great things about Agile is it focuses on teams. One of this very serious problems about Agile is that it focuses on teams. Your team operates within a larger organization within a larger value stream, more than likely. And you need to optimize all the flow that you're involved with, not just locally optimize what you're doing because a bunch of local optimizations can tend to add up to a mess. So just to summarize, we can do this. We can take Agile back. We can get back to the heart of what Agile was all about years ago, where it really was about owning your own process, about learning how to get better, about improving, about experimenting, about doing better. So thank you very much. And I'm happy to go to questions now. I'm gonna dive out of my presentation and dive into the Q&A chat box. Yes, so one question, first question, from Vismane. Most frameworks have inbuilt continuous improvement mechanisms. They do and they don't. So here's an observation for you. Do you really think a framework will tell you how to abandon the framework? Does Scrum have improvement mechanisms in it to abandon Scrum and say move on to Kanban? Does Safe have mechanisms in place to move beyond Safe? No. Yeah, there's local improvement strategies, but this idea of going beyond what the framework wants you to do, there might be a little marketing, but they don't really give you techniques to do that. So do Kaizen methods outperform a comparison? Yes, they do. Yes, they do. This was my point with the Apex Predators, the Amazons, the Ebays, and the Googles of the world. Do you think they're doing Agile frameworks? No, they're not. They might be adopting ideas from them, like why wouldn't you, right? They'll reuse what they can, but no, they're not gonna limit themselves to a framework. That would kill them. They wouldn't be competitive. So another question, should we focus on having no frameworks? Well, like I said, start where you are. There's nothing wrong with these frameworks. Do you have value? Don't get me wrong, they really do. And you gotta start somewhere and very often adopting a framework can be your first improvement strategy, right? Let's adopt that framework, solve whatever problem that framework solves, improve, get better, but then realize, oh, now we need to do something else because we plateaued, we're now in framework gel. So then continue on. And the next solution might be, well, let's take another step and adopt another framework. Or it might be, let's actually become a learning organization and adopt a technique like Guided Continuous Improvement that is a fundamental strategy that enables you to improve forever. From Laxmana, and I hope I pronounced that right, or close, frameworks introduce so many practices. When we want to go back to basic, what are the primary metrics we can follow to learn to validate? Oh, that's a wonderful question. Well, there's so many metrics, that's right. So completely avoid articles like the best 10 metrics or the most important 10 metrics that you can adopt for agile. There might be nice metrics, but they might not be nice for you. So there's techniques such as Guided Continuous, I'm sorry, OKR, Objectives and Key Results, GQM, Goal Question Metric, and KPIs, Key Process Improvement. And the basic idea is that there's similar techniques, they're all slightly different strategies, but the same basic flavor. And the idea is start by asking yourself, what do we want to improve? So if you want to improve on the quality of your work, then you'll collect quality metrics. If you want to improve on customer satisfaction, then you'll adopt metrics around to measure customer satisfaction. If you want to improve both, well, then you would collect metrics for both of those topics. So the thing is, is what's important to you? So different teams, different organizations, well, different priorities. So depending on what you're currently trying to improve and where your current challenges are, that will drive the types of metrics that you need to collect. Now there's some very common metrics that chances are pretty good that you'll collect cycle time and others, but the metrics that you collect must be driven by what you're trying to achieve. And because what you're trying to achieve will evolve over time, so will your metrics. So, and this is something that we built into the Disponential Toolkit years ago, is that to give you options for approaching metrics, and then, how do we actually choose the right metrics? Okay. Here's a question from Balaji. I was always thinking, dad is a framework. It started out as a framework, to be fair. Although it really, we originally called it a framework because that was the term we had. And a few years ago, we realized that we were always sort of out in left field. We were, we would get compared, the gardeners of the world didn't know how to compare us with like, say, safe and scrum and others. So, and the problem was, because it wasn't really a framework. It was more of a toolkit. Instead of telling you what to do, we were telling you what to think, and we were giving you options. So, it's, in comparison, the frameworks basically give you a fish. They feed you for a day, they solve a certain problem, which is good, very important. They feed, you know, they keep you alive. They feed you a fish, right? Whereas a toolkit like Disponentials, we've renamed it Disponential because it was about more than just delivery, but a toolkit like Disponential, which is a little more complicated, you know, to be fair, it teaches you how to fish. It teaches you how to actually improve. And so it feeds you for life. And I think this is the major difference. So, quick answer, Disponential is not a framework. It's a toolkit, and that is an important distinction that it's worth thinking through. Okay, here's a question from Sunil. Sometimes leaders, not coaches, can insist on adopting a framework. Yep, they buy into the marketing rhetoric is what it is. My hypothesis is that they do so because something goes wrong. It can, if something goes wrong, can be blamed in the framework. That might be the case. That's a bit jaded, and certainly the framework would get blamed if something does go wrong, but I don't think that's not their primary goal. Their primary goal is they believe that framework's gonna help, and it might, but the challenge is, is have they chosen the right framework, or did they choose it because it has a pretty poster, or did they choose it because it makes sense? Are they, is leadership able to follow through? Do they even know how to do a transformation? Do they even know how to do an adoption of a framework? Are they willing to stick with it as long as it requires? It's often more effort than they think. So, but yes, and then if they do make mistakes, and mistakes often happen, then the framework gets blamed, but I don't think they go in with that intense, you know, although it does happen. Industry is so conditioned to think of frameworks that hearing someone talk about no frameworks might just scare them. Good, I want to scare you. I hope you're scared. You should be scared. You know, we're in the new normal, whatever the new normal is, and nobody can tell you what the new normal is. The only thing I can tell you about the new normal is it's gonna be way more competitive than the old normal. Anything beyond that, nobody knows they're talking about right now. But anyways, the, yeah, you should be scared. I'm asking you to think, and that's pretty scary. I'm asking you to take responsibility. I'm asking you to actually make decisions and be accountable for those decisions, and that can be pretty scary if you just desperately want to be told what to do. But you know what? If you want to be, you know, if you're hoping for some magic cookbook, some magic framework to solve your problem, you're a follower, you're not a leader. And in the new normal, in this hyper competitive environment that we are very clearly going into, the follower's not gonna make it. The leaders are gonna struggle. And we actually saw this. You know, if you remember back, you know, in March or April when things started going really poorly, many organizations did really, some organizations did well, Amazon, Thrive, eBay, Thrive, and other organizations got their heads handed to them. Which type of organization do you want to be? I think that's a valid question. So anyways, I'm out of time. Thank you for all the likes and the thumbs up. So I appreciate that.