 Hi there, and thanks for the introduction. So, I want to talk to you about my experiences of scaling Agile, and why looking back over the last 20 years or so, I don't believe it's ever worked. And to be brutally honest, I don't hold out any hope for scaling Agile in the next 20 years either. So, a nice happy talk then. My experience has been that the history of Agile has been filled with pockets of small, ever since 2001, scaling Agile has been the holy grail. Many, many organizations in the last 20 years have been willing to pay lots and lots of money for this elusive Agile transformation, this elusive Agile organization, Agile at scale. And teams themselves have been hoping for it as well, because it would then mean that their successful team is no longer fighting the organizational bureaucracy and bumping up against the edges of the traditional commander control waterfall organization. And we've seen lots and lots of people have success at the micro level. So, there've been lots of successful teams and no conference is complete without at least one or two talks around our transformation journey, but none of them have ever really succeeded. They've always been, and we're not quite there yet, and we need to do this or we need to do that. It's been so elusive that even SAFE became popular for a while, which really smacks of desperation, and the most popular framework is arguably one that never even existed, the Spotify model, with that desperate for scaling Agile. But Agile was never meant to scale. The one unspoken secret that I'm going to confess to you now that I don't think I'm the only person in the Agile world tried to keep was that deep down we all knew that Agile didn't scale. It was never going to scale. Part of us wanted to believe that someone would work it out one day, and maybe we could pick it up from them. I would say part of us worried that if perhaps we admitted it, admitted that it didn't scale, admitted that it didn't work at the enterprise level and never would, then maybe it might mean that whatever we were doing successfully at the micro level would be stopped, and there would be no Agile at all. And perhaps small Agile with the carrot of possibly scaling Agile to the enterprise level one day was better than nothing at all. Now these scaling frameworks that have become very popular, you've seen the horrendous Deloitte tube map and the safe abomination. The organizations that I've seen go down those routes are desperate. They're not bad organizations. The people that are buying this stuff are not bad people. They want success for their organization. They want good things, but they don't know how to do it. So they trust the brands. But those brands have the most to lose if we were to do things properly. Now, what do I mean by properly? Well, when I say properly, I mean not pinning your colors to a mast and selling the hell out of it. Many years ago, a colleague of mine at BT, Kerry Buckley, penned the manifesto for half-assed Agile software development. And as it says there, cobbled together one Saturday morning before breakfast. Kerry's got a great sense of humor. And in my experience, some of the best jokes are ones that are true. And certainly back at BT and some of the other people that we were talking to at the time, I don't think it's really changed a lot since, were saying effectively, yeah, we like the idea of Agile. But, and you've heard the scrum butts, you've heard the agile butts, you've heard dark scrum, basically this idea that, you know, we'd like to do it, but it's not got a chance in hell of ever working because we're an enterprise company. So it's a lot of truth packaged in a funny Agile manifesto-like joke. In practice, what I've seen in organizations that have tried to scale, especially the ones using things like SAFE, it's been effectively the equivalent of saying self-organize like this, which is so oxymoronic and that word is so applicable as well, so relevant. We've been trying to do something that was not destined to work for good reason. Agile is a solution to a problem, but it's not the only solution to all problems. For certain questions, Agile approaches are the right answers. And the truth is that over the last 20 years, we've had more and more of the types of questions that Agile is the right answer for come up because things have become more complex, they've become more rapidly changing, they've become more volatile. So it makes sense for there to be more instances of Agile than there were 20 years ago. But Waterfall hasn't gone away over the last 20 years and I would argue that it actually shouldn't go away. And Agile will never be the one way to do things, ever is my proposal. What has been good over the last 20 years is this acknowledgement that actually the mechanical metaphor that organizations have traditionally been built on focused on taking inputs and efficiently turning them into nice packaged, repeatable, predictable outputs through lots of structure isn't the right metaphor in these new circumstances that a lot of organizations find themselves in. These circumstances call for a lot more focus on effectiveness rather than efficiency. Not completely though, because if we kept on focusing on effectiveness over efficiency, we'd never really take advantage of our innovation. We'd never really get profit. We'd never really get our return on our investment. So it's a balance. It's a balance that's a lot more heavily weighted in favor of an Agile approach than a traditional approach. And the organic metaphor is a lot more relevant now than the mechanical metaphor, but it's not about going from one to another. As well as waterfall not going away, Agile's not going away. I mean, I hope it does. I hope waterfall goes away and I hope Agile goes away. I mean, it shouldn't be a battle. It shouldn't be either or. Perhaps if I look back with a positive interpretation, I could agree that actually a lot of the progress that we have made in the last 20 years has perhaps in large part been down to the fact that we have fought so hard almost religiously, evangelical against institutionalized anti-agility or institutionalized fragility. What's interesting now, for me at least, is whereas I used to be asked to talk to leaders about Agile, what's interesting for me now is that I'm now being asked to talk to leadership teams about almost slowing down their appetite for Agile. I want them to calm down a little bit and just think a little bit more instead about becoming an Agile organization, become a more coherent organization, become a more resilient organization. Helping a leadership team understand the context that they're in and then being able to flex their leadership styles, their structures, their processes to meet the demands of their particular context at that point in time that the organization finds itself in or perhaps proactively wants to move into. Culture itself is changing or our appreciation of culture is changing. Historically, we've been very much led from the top and that's normal in a predictable environment where our leaders have risen to their position because they are the best at what they do, because they know the most. Traditionally, we focused on results and if we aren't getting the right results, we should change our actions or perhaps other people's actions. But what we've missed perhaps along the way is that our actions are based on our beliefs and our beliefs are formed and reinforced by our experiences. Now, why we've missed that is because they're not as visible. Results and actions are a lot easier to see than beliefs and experiences. But beliefs and experiences are really important for resilience both at the organizational level and the individual level because if we are in a domain where we can't expect our leaders to know all the answers and tell us them in advance, then we need to encourage other people to find those answers. We can't expect the answers to be given to us. Equally, we can't wait for the question to be escalated up the chain and the answer trickled back down because our need to act sooner is a lot greater than it ever was. But unfortunately, we need empowerment to make this work and with empowerment comes greater potential for inconsistency. If I let everyone work things out because I know the leader doesn't know then everyone could do things in their own way. We can't standardize the unpredictable. We can't standardize the complex. But what we can standardize are our beliefs and we can focus on creating more experiences that foster consistent and coherent beliefs and that way we can be more likely to act coherently even if those actions aren't standardized. Well, KPI, one key performance indicator that I think leaders need to pay a lot more attention to when creating and maintaining and evolving a resilient organization is motivation. Now that's not only because motivated people perform better. It's not only because it's key to attracting and retaining and enabling the best talent but also because motivation becomes an indicator of coherence. If our people expect a certain type of leadership from us, a certain level of autonomy, but we give them something else, then motivational debt is created and demotivated people are not very resilient. Resilience has been absolutely critical for these last 12 months across the globe. And if I've noticed anything, it's motivation that's a really important aspect to maintaining our personal resilience and we have no hope of becoming a resilient organization if our individuals are not resilient. So finally, what do I mean by this scaling agile will never work? Well, it's not that we can't get agile principles throughout the organization. We can't achieve an organization that is built on the agile values. It's that an agile organization is also a mox... It's also that an agile organization is an oxymoron because it's highly unlikely that an organization will be completely agile as per the principles of the agile manifesto or the rules of scrum. An organization's culture is an ever-evolving thing. An organization is an organism and its culture should be treated as such. It's the appropriate metaphor, not a machine designed to churn out widgets efficiently. And if we've learned anything, that resilience is the order of the day and the order of the future. Resilience at the individual level, the organizational level, the society level, the global level. And we get resilience through evolution, through emergence, through not ever achieving our end state but continually looking at where we need to be next. Yes, we need effectiveness. Yes, we need efficiency. We need planning and we need responsiveness. And that's why we shouldn't be building an agile organization but more a resilient and a coherent one. Thank you.