 First of all, I'm sorry, we're not all together. This is my third Zoom call of the day and it's only 7.30 in the morning and then I go on to late o'clock tonight. That's kind of like the way things are these days. So I'm not gonna use slides. What I want to do is talk about the subject and then open up for questions. Yeah, so start to build them as we go through. There are many disadvantages of reaching the age of 66 which I am now. One of which is your knees aren't quite up to the walk in you want to do. But one of the advantages is you've been through the cycle of management fads so many times you start to recognize it and the fad cycle is very simple. Something which was working before stops working and some brand new idea comes on board. It has to be right time, right place and I'll come back to that in a second. It becomes extremely popular. It goes through an adoption cycle. It starts off with the enthusiasts. A lot of things die at that stage. Some which survive it, then go through what Jeffrey Moore called crossing the chasm and that's a switch from people wanting to know how it does it to people wanting to know what it will do for me and that's a key switch in sales and other strategy. Agile went through that some years ago. So it was initially a bunch of enthusiasts and then it started to scale up and then it became the way that people did things. Now, then the trouble is it then gets adopted as a universal and it starts to fail in various aspects or it doesn't deliver what it's promised and then people start to use the mindset word and the culture word. So the problem is not the method or its application. It's not the idea or its application. That's still visionary and wonderful and brilliant. The problem is that people don't have the right mindset. Our culture doesn't prevent it. Managers don't support us. There's a series of standard statements you see and I've seen it with business process re-engineering. I saw it with knowledge management. I saw it with learning organization. I saw it with Lewisian strategy and I'm now seeing it again with Agile and it amazes me that people aren't learning from this. So there are a few lessons we can come out of this. One is part of the problem with method adoption is the assumption of universality. One of the ways we explain this in complexity science is to say people are trying to create a context free method in a context specific world. So different things work in different types of system. There isn't one universal. So to take Agile, for example, Scrum is an extremely good technique for taking half formed ideas and through fast cycle iteration, moving them into something which is concrete and structured in a my language complicated. Nothing wrong with that. Hugely powerful, one of the best techniques invented in software development in the last 30 or 40 years. No question about that. The trouble is it's not that good but actually identifying user requirements and it's based on a manufacturing metaphor. It assumes there is something to be produced which is a general problem with Agile. And so instead of starting to create, for example, what we call pre-scrum techniques, i.e. different ways of handling ambiguity, starting to look at techniques for unarticulated need identification and starting to try and find ways in which we can look at things more systematically, people try and do Scrum harder or they try and bolt it onto other methods which has been the safe approach and create a massive construct. And when it doesn't work and those systems are prior, I will not work, then you use the mindset word. So let's deal with mindset and then come back to where we need to go with Agile. So, first of all, the very phrase itself is problematic. The idea that the mind can be set really is developed from the idea that there are mental models. Now, that was a cute idea back in the 80s. Yeah, with Argyris and other people, they got picked up and heavily popularized by Peter Sengu. And if you go back and look at it, you'll find that period was when we were all getting really excited about the tremendous power of computing. And I started off programming with punch cards, which means I have coding discipline. Now you get a compiler on card three, you can't try and get it right first time. And I still remember at school, we were taught how to use punch card machines and told if we acquired that skill, we'd have a job for life because that's what people thought it was about. So I've lived through that period from when IT was just a sort of vague thing and it was only used for huge number crunching. The year I was born, 1954, famously IBM said there was only a market for six mainframe computers worldwide because only six cities were big enough to justify using a computer for their telephone directory. So that's been my life. What the problem with the whole mental model thing is it assumes that a human mind is like a computer. So it's got a series of programs that it's run. And you find people using computer language, they don't just talk about mindset, they say we've exceeded our bandwidth and they use a computer metaphor to describe the way the human mind works. And this is just really, really bad science. I pulled my daughter when she was 16 out of A-level psychology, it's out of A-level psychology because the opening chapter of the textbook said the basic assumption of psychology is that the human brain is a limited capacity information processing device. And if she was gonna be training that for two years, there were better things for her to do. So despite my hatred of sociology, she did that instead and became an anthropologist. So the computer model of the human mind was deeply problematic and it remains problematic to these days. It's almost like the language of programming. The language of cultural changes will decide what culture we want and then we'll instill that culture in people. I will program them. It's a kind of like Brave New World or 1984 type scenario if you actually look at it under the pins. Now the reality is carbon isn't silicon. Humans beings make decisions in very different ways from computers. And there are two key aspects on this which I want to bring out and then think through some of the implications. So the first is what's called inattentional blindness. So you do not see what you do not expect to see. And this is actually a matter of energy efficiency. Remember that the whole of biological evolution is about reducing energy costs because energy is expensive in terms of lifespan and everything else. So most of the time we'll scan about 2% or 3% of the available data. That scanning will trigger a series of pattern based memories either partial or complete. Some of those are body based memories but I'll come back to that in a second. Let's just keep with the mind in the sense of abstract thought for the moment. So that will trigger a series of memories of things you've lived through, things you've heard and things that you've been taught. Yeah, that's the sort of all the stuff that we know but can't articulate the stuff which is articulated and the stuff which is codified the sort of three types of knowledge. Highly explicit, highly tacit and narrative based knowledge which sits between the two. So basically we trigger those series of memories that all sounds really interesting. And then we do something called conceptual blending. We blend those patterns together and that triggers a course of action. And that's how we make decisions. It's a first fit pattern match. Critically it's not a best fit pattern match. Now that's important and you can see why it happens in evolutionary terms. If you think about the early hominoids on the savannas of Africa something large and yellow with very sharp teeth runs towards you at high speed. You don't want to artistically scan all available data look up a catalog of the flora and fauna of the African belt and have an identified lion look at best practice case studies on how to avoid lions. What you want to do is to make a decision very, very quickly based on a partial data scan and then run a lot faster than your companion. So that's how we evolve to make decisions and that isn't gonna change in the foreseeable future. So the key thing in decision support and decision-making is actually what stimulus should give people and what memories it triggers. So I'm gonna repeat that because it's important is how do you stimulate people and what memories are triggered? And actually what is known as mindset is actually in the individual a triggered set of patterns. It's a triggered set of memories. It's not actually fixed. It may form a stable pattern. At certain times, particularly if people get perverted in the way they see the world or they get limited experience but it's not a mindset and it's not a model. It's an associative set of fused and blended memories. The other thing which is important to realize on this that there are chemicals in the brain that ensure that we never remember anything the same way twice. This is Walter Friedman's famous work. Now the reason for that in evolutionary terms is by introducing constant mind and mutation. You increase the ability of humans to actually stimulate or do things in a novel way. So we will remember things differently. So that's kind of like key fact number one and linked to that is the famous experiment which has been repeated and validated many times. You give radiologists a batch of x-rays. You ask them to look for anomalies. On the final x-ray, you put a picture of a gorilla which is 48 times the size of a cancer nodule and 83% of radiologists don't see it even though their eyes physically scan it and the 17% who do see it come to believe they were wrong when they talked with the 83% who didn't. All right, now in that simple experiment and what I've just said, I've just invalidated the whole process by which user requirements are defined because everybody comes into it with a preview of the mindset and actually they're not gonna see things which don't fit the pattern. They won't see anomalies. So this concept of conceptual blending linked with inattention of blindly has memory triggering rather than mindset or mental models in that sense. So that's key. The other key thing and actually there's three come to think of it. The second key thing is that we don't make decisions in isolation from other people. And this is a key finding from both cognitive neuroscience and from complexity theory. What matters is how people connect about how they connect and who they connect with is far more important than who they are. Particularly during times of extreme change or stress and we're living through that now, who you're interacting with actually has a much more profound influence on things and who you are originally. Anybody with teenage children will know this that when they hit puberty, what you most worry about is who their friends are because they've moved from you being the prime influence to their peers being the prime influence and the friends, teenagers have their own puberty basically form them for a very long period of their life thereafter. So if it goes wrong, then you've got a problem. So this collective interaction is also a part of what we're talking about and the large part of that is informed by the stories people listen to around water coolers. It's the stories you get told when you join a company. Some of our work, for example, is to capture those stories. They're often called sacred stories. The stories that everybody gets told, the stories about the founder and cognitive edge is now 25 years old and Kenevin as a framework is 20 years old. Sorry, see all the way around. Kenevin as a framework is 20 years old, cognitive edge is about 15 years old. But even then I founded it. People still tell stories. They were doing it yesterday when we had a sort of big webinar to celebrate 20th birthday of Kenevin. About the first time they met Kenevin, the first time they met me and I've heard them tell them those stories are part of the embedded culture of an organization. And they basically frame the way that people see the world. So that is a kind of like mindset but it's not a mindset of the individual. It's a mindset of a collective pattern which is built through effectively a mixture of experiences and narrative heard and repeated in the informal networks of the organization, not the formal organization. And that's gonna give us another way that we can start to manage this downstream. And then the third thing is what's called post-Cartesian concepts of consciousness. So if you look at the dominant Western thinking and India is kind of like a halfway house on this because of the good and bad influences of English educational system on India. But at the same time you've got collectivist religions like Hinduism and so on. So basically the brain is not the sole repository of consciousness. What you see in Western thinking is a mind-brain dualism. It goes back to Descartes, it's the concept of Cartesian models of consciousness. And Descartes separated effectively the mind from the body. Midgeley and other people have argued I think correctly that the reason he did that was to deal, he was scared that he might get subject to a heresy trial. He'd just seen other people like him burnt alive in Italy. And so by separating the body from the mind he effectively created that this is the role of religion, this is the role of science. And he opened up the possibility for science not to be in conflict with religion. And that's the historical context of Descartes, which you understand it. But the reality is that we now know that consciousness is a distributed function. It's not just the brain, it's the body, it's social interactions. And if you look at Andy Clark's work on scaffolding these common narratives effectively provide this highly abstract, ephemeral framework which actually informs the way we make decisions that is part of our consciousness. I don't get me wrong here, I'm not getting mystical. If the brain gets damaged, you lose consciousness. So the brain is the origin of this sort of stuff but it's distributed. So take another example when you pull your hand away from a fire, the left hemisphere of your brain kind of like controls that movement. It's called an autonomic process. And if you actually map the brain, it's actually activating after you've moved your hand away. Some people think this means we haven't got free will but they're stuck in a cartesian model. They assume the brain has to direct the body. The reality is this is called autonomic processing. Yeah, and the brain is firing after the event to double check if the reaction was right this time. If the reaction proves to be wrong, then the novelty receptive part of the brain, the right hemisphere will come into play. This is not creative logical. Don't buy that left, right brain one since it's just bad science again. The right hand side of the brain will come into operation and we'll actually think about the problem and double check and maybe change the automatic response. And so that's kind of like, this is a very crude approximation. There are quite a complex set of processes involving chemicals and God knows what else. Now the autonomic side of the brain handles something like 60,000 items per second. The novelty receptive handles about 20,000 items per second or even less. So the energy cost of using the novelty receptive part of the brain is very high. So we don't do it unless we've really got to do it, which explains why radiologists don't see gorillas in X-rays because they're not expecting to see them. If you want a more common place explanation of this and interestingly the economists followed cognitive neuroscience, this is what Cardamom call thinking fast and thinking slow but autonomic novelty receptive is a better idea. So all of these things are important to understand because they basically say this whole issue about why people make decisions, how people make decisions, yeah, how they respond to change, how they respond to novel ideas is something which is inherently very complex and very messy and it's not subject to simple linear cause and effect models. You can't say if senior executives back are agile thing it will work. You can't say if people have the right mindset it will work because these aren't things in a linear causal chain and they're not deterministic and they can't be programmed. So what you've got and this is the basic lesson of complexity theory is you've got a system which has complex dispositional states but no causality. Now that's a scary thing to contemplate. I generally find it easier to explain in parts of India, China, Africa, Asia because the religions there if we say particularly Taoism in China has never lost the concept that some things just are. There's no reason for them to be. It's just the way things fell out this time and that's not necessarily fatalistic. It actually is that to be good science. Each context is actually unique. There may be common patterns but there's no predictive framework within that. You've got a dispositional system, not a causal system. So what matters is how do you influence that dispositional state? Because this is a co-evolution of method, idea, engagement and people and everything else. So what I want to do now is to go through three or four things about what you can do there and then finish in time to about 10 minutes or so for questions. So there are several things which follow out of that. First of all is the realization of what I call bounded applicability. There was nothing wrong with business process re-engineering when it came in. It was brilliant for manufacturing processes for highly constrained ordered systems where there was predictability. The trouble is people liked it so much they then tried to apply it to things like customer relationship management and employee engagement which are highly complex systems which don't have rigid constraints. And of course then business process re-engineering started to fail. Now learning organization came along at the same time and sort of plugged it up and it was kind of like a dichotomy. So you have rigid processes and then you have inspired leaders. And that's actually still around today if you look at it. But the problem with business process re-engineering wasn't that actually it was wrong it was right within boundaries. Nothing wrong with it in those boundaries but when you extend it beyond the boundaries you need to do something different. We've seen the same with agile. So agile starts off with a mixture of DSDM, XP, scrum and a few other things. If it had stayed with XP although that's I think more authentic to agile in terms of XP and back to working people like that then I think it would have been more authentic but nobody would have heard about it. This is the paradox, all right? It wasn't until Can came along and created scrum with a highly codified highly abstract method with certificates that actually agile scale. So this is paradox of codification and abstraction and necessary for scaling that they involve loss and loss of authenticity to the original of the idea. And the danger is the codification goes too far. So you see that business process re-engineering comes along, it's taken too far it starts to fail, there are then two responses. One is to realize that it's reached its boundaries and you need to think differently. The other is just to try and do more of it harder and hope it works that way. And that was called Six Sigma or as Gary Klein famously called it Six Sigma, all right? And we see the same in agile. We start to realize that some parts of agile are working and I think I would argue one of the reasons is that over codified, over structured, over focused on certificates and you get these crazy wars between scrum and Kanban and lean and all these sort of fights most of which are meaningless. And instead of realizing that you've got some extremely good methods which work in one context and will not work in other contexts. The attempt is, well, if we only did them harder or with more rigor or with more enforcement somehow or other would magically work. And that's where we get things like safe, yeah? Which is the agile equivalent of Lean Six Sigma. It's a highly codified, highly structured and it's kind of like the wrong evolutionary pathway because it still assumes universality when you want this context sensitivity. So one thing you can do to get credibility with people because good coders work around this stuff. I've gone into five safe implementations in the last couple of years which have actually failed. But the amount of money spent on the failure is so high that nobody will basically earn up to it. And you chat with the people who've done it and fundamentally what they've all done and done very effectively, yeah? Is to work around the formal method. So what's actually happened is the informal network has said, well, we've got to live in this place. We've got to make it work. So that's what we've got to say we want to do but the reality is we'll do something different. And we saw this in the early days of our job by the way I remember working with Telstra and they had waterfall projects and waterfall projects are perfectly legitimate for large infrastructure work. And but because nobody got promoted, if you weren't agile, they did one year sprints just to kind of like make the point, yeah? So you have to treat people with respect. They know the limits of formal systems. They know you actually have to have a mixed methods approach but they will gain the system if you try and take one thing in a doctrine in their fashion. So that sort of respect is kind of like a key thing that you need to do in the initial stages. The other thing you need to do is to recognize that informal networks in companies are more important than formal networks. In the original work I did in IBM which gave rise to the Canadian framework. I think I've published this about 18 years ago in an article called complex acts of knowing which is now I think the third most cited article in the field of knowledge management has won several awards, right? But what's not because it's a particularly good article. I was just the first person to use complexity and knowledge. So that was advantageous. And one of the pieces of work I did there is a balance between informal and formal communities in IBM. And the ratio was 60 to one. And that was only between people using virtual environments for collaboration. It was probably bigger in other words. And the real trust and the real values of the organization, the culture of IBM was it is informal networks, not its formal system. Because the informal networks made the system work despite itself. And in modern organizational design, something I was talking about in the workshop yesterday and they pick up again today's session, you actually build and stimulate the formation of an informal network. You don't just want it to happen by accident. Techniques like social network stimulation, for example. If run every six months, will ensure that within 18 months to two years, everybody in the organization is within three degrees of separation of everybody else based on a trusted work relationship. Now, if you've got that type of network density, there's a whole body of stuff you don't have to formally manage anymore. And you can start to use the informal networks to identify clusters of stability which become formal communities and formal practices. So it's kind of like you may have a formal garden and a wildflower garden. If the formal garden starts to get, you know, problems with disease, because it will, it's highly formal, it's highly, it's not as resilient, you start to go to your wildflower garden to find new things which bring in disease resistance. And that's the informal formal. So one of the ways you manage culture is to interconnect people in tight informal networks. And you won't know who's connected with who, but you'll know the network is connected. These things, they're like the fungus which in soil intermeshes with plant roots and provides a symbiotic relationship. The plants couldn't flourish without the fungus, but the fungus is difficult to find and is deeply entangled and spread throughout the organization. So intervention number one, build your informal networks, place more reliance on them and less reliance on formal systems, because also the informal networks are the water cooler conversations which define your culture. The second thing is map the culture. And by the way, cultural mindset mean the same thing in popular use. So I'm gonna use the culture word more in the sense. Map it. So we do this for example, and there's two ways we do it. One is we'll take a series of gape and void cartoons. You can see some of them behind me on the wall along with the Starbucks Mug Collection, which means I haven't flown anywhere for nine months. It's got no new additions, which is depressing. So we present a series of cartoons, people, and we can do these which are culturally specific. In Japan, you would use a different style. And then in America, for example, people choose the cartoon which most represents what things are like around here which is a definite culture. They tell a story of their own experience or their friend's experience which is a proxy for their own without accountability which illustrates why they chose the cartoon. They then self-interpret that cartoon into a series of geometric shapes. These are designed to be ambiguous so that you don't know the right answer, shifting to a level of abstraction. And then from that, we draw contour maps which map the attitudes. Now to me, we should start talking about attitudes, not mindset or culture. Because attitudes are a lead indicator, whereas compliance is a lag indicator. So if I can measure attitudes, and if I've got a big contour map, I've got clusters here and clusters there. I've also got outlier clusters who are the 17% who are seeing things differently and they've seen a gorilla and the 83% are listening to them. That's ability to map that and say, okay, is this what we want to do and we want something different? But if we want something different, then we start to nudge the system so it shifts in the direction we want. And kind of like this is the second key message I want to bring out, which is called vector theory of change. In a complex system, you start journeys with a sense of direction, you don't have specific goals. And the trouble is the management consultancy market, the popular methods market, has got everybody rigidly focused on defining where we want to be without paying attention to where we are. The reality is evolving from the present is a lower energy cost, is a more resilient solution and more effective than trying to achieve an unattainable goal in the future state. That's sort of eschatologically an error. I'm using eschatologically deliberately because this has a sort of religious fervor behind it in the true believers in Agile. Now they have some of the worst aspects of Bible Belt fundamentalism about them at times. So understanding a map in the water cooler culture is key. And then the third thing, and the thing I really want to sort of finish with and the most important thing actually is this whole concept about knowledge is enacted and embedded. What matters is what you do, not what you say. And the myriad problem in the company is to adopt the language of Agile, but then not be Agile in practice. When I work with leaders, one of the things I say to leaders is you've got a bad rumor spreading about you and people are saying things you don't want to hear or what you think are incorrect. Don't tell people they're wrong. Don't go on the public platform. Don't issue press releases. Go out and physically do something which makes that story impossible to tell. And this is an issue for managers and everybody else. The way we actually manage determines the culture. The way we actually act in the system creates the culture. Not the things that we say. And there's far too much verbalization. I mean, a sideline on this. One of the studies I did in IBM is we went to the corporate mission statements which are now called purpose statements or principle statements. I mean, they're all the same thing. It's just people use language to try and pretend they're doing something new. So we took all the mission statements of I think 150 IBM companies, sorry, clients. And we did a linguistic analysis on them and they're sort of 85% say the same thing because their assemblies are platitudes. There's only so many ways you can say we will focus on our customers. We will focus on speed of delivery, all these sort of nice phrases which everybody combined to that. A manifesto does that well. A manifesto gives us a verbal statement of what we would like to achieve. That's all good news. What then matters is what we do, not what we say. So if you don't live that agile journey in the way you manage, you've got a problem. And part of the problem is if you try and enforce methods rigidly and you don't recognize it as the occasional distinction, you've got a problem. So I've seen people, for example, who absolutely insist all sprints must be two weeks. I mean, that's what the manual says. And your retrospective must take place in this format and mustn't take place longer than that. No variation is allowed. And that will just mean you drive the behavior people want to exhibit underground. It will actually take place before the meeting or around the water cooler. And this sort of inability to recognize flexibility to recognize people's needs is a key issue. So kind of like the third lesson I'm drawing out is this respect, the fact that hypocrisy is a major factor, fairness is a major factor for humans. If you ask people to do things you don't do yourself, yeah, then they won't follow them. And the more aspirational the things you say you want, the more likely you are to fail them in practice. Management is about pragmatism. So I want to finish off with something which relates to that, which is called the see attend act framework for sense making. And if you look at traditional decision theory, it basically all popular decision theory, I should say. And it basically assumes if you put the right information in front of the right people at the right time and they have the right competencies and the right training, and if they're in agile, the right certificates, then they will make the right decision. Now, that's actually nonsense. First of all, whether we see something in the first place is questionable. Remember in the intentional binders? So whether we see something matters. The reason we do the landscape maps is to make outliers visible. So for example, we'll do that in mass engagement of employees in decision support. We'll basically present them with the current situation, get all employees to interpret it, and then draw on the maps so we can find the employees who are thinking differently. So whether we see something requires a different approach and it requires us to actually have that sort of ability to stand above the system and see patterns. Whether we'll pay attention to it is another matter. The fact I've seen something doesn't mean I'll pay attention because I've got all sorts of other distractions. So if you want people to pay attention, you have to specifically focus on that, you have to create contrast. We do work, for example, with what's called transgenerational pairing. So we put new joiners together with people who are about to retire with people in middle management in trios and get them to look at problems and we do multiple trios in parallel. And because you've got this intimacy with two people you've never met before or think differently, you pay attention to them, whereas in the round you actually wouldn't. And then there's the can you act on it. And this is where everybody gets it wrong and they don't understand senior managers. So after 9-11, and if you don't know it, I was working on counterterrorism programs before and after 9-11, I was in Washington the day before 9-11, actually in the part of which got hit by the plane and flew out that night and picked up the news the next day and then sort of got flown back and we did a huge amount of work. And after 9-11, we had the whole of Clinton's al-Qaeda team together in the Blue Mountains to go through Kinevin framework complexity theory in the context of 9-11. That itself was fascinating. It was three days and it was absolutely fascinating. But at one point, I mean, Al Gore was there because he was part of that team. And if you don't know it, there was a presidential order which would have been signed if Gore had won the election or if he hadn't been displaced by judicial coups. Sorry, I'm taking my position on that. We should have had F-14s in permanent patrol above Washington, New York with authority to shoot down civilian aircraft. This is something not many people are aware of. But al-Qaeda's plans for 9-11 were actually known and being gained. And I remember asking him, do you actually think you would have signed that? And he thought, and he said, well, actually probably no because to sign an order to allow military aircraft to shoot down civilian aircraft after 9-11 is an easy call. Before 9-11, given the three disasters which had occurred before, it's probably not acceptable. And senior leaders are working in a context of political, multi-actor environments, which means even if you have told them what to do and even if they know you're right, they may not be able to act on it. So if you want to change initiatives, Sea Attend Act is important. You need to look at each of them as a distinct phase. And that actually applies to change initiatives as well. So I hope I've poured enough cold water on all the mindset, culture-type nonsense, which is just an excuse for not changing. And I've tried to give you three things you can actually do which would achieve those changes, all of which are actually based on the mixture of natural science and experience. And this is called pragmatism. And agile, in my final stage is if agile got a little bit more pragmatic and a little less idealist, it might actually make a difference. So thank you for your time. I've done my 40 minutes and we're now open for questions. Awesome, awesome. Thanks a lot, nice to have you back. Oh, I'm not sure that's what my state might say. I mean, looking at some of the questions, I mean, watercooler chats now, I think there's something too important to understand here, right? Negative stories are part of life. It's my big objection to techniques like appreciative inquiry, now which I sometimes satirize as being rather like the Monty Python film, Life of Brian. If you know the final scene, they're swinging backwards on, forwards on the cross, singing always look on the bright side of life, right? Which is a bit cruel, but that's how appreciative inquiry feels to me. The reality is if you look at the fairy stories you tell your children, they're negative, not positive. People learn through fairy stories, they don't learn through success stories. We have games we run for organizations where we run them through a one day, three day iteration in which wherever they do, they fail. And at the end of that day, they're scanning 20 times more data than they do if they succeed. So failure is actually valuable. And if you got, and gossiping is natural, you will not eliminate it, yeah? Because actually we evolved as malicious gossips because it gives us learning capability. The secret is to understand it and if necessary redirect it. And also good managers listen to the cynics and the naysayers, they don't listen to the yes, the yes man, yeah? So negative stories are part of life, live with them, learn them, capture them, understand them and by your actions contradict them, not by your words. And sorry, somebody just said culture dictates if a company is gonna have a negative water cooler chart or a positive one. First of all, water cooler charts will be positive and negative in crude mixtures and it's that which determines the culture and not the other way around. You've got that the wrong way around. Any more? I'm looking in discussions, I'm not sure if I'm meant to be looking somewhere else guys, yeah? No, I think we have two, we have some questions. We'll just have one more. Okay, so am I looking into discussions? I don't know, Q and A, sorry. Q and A, Q and A. Yeah, that helps, all right, it's a bit obvious, yeah? Yeah, first of all, Agile needs to stop becoming a bandwagon, yeah? Again, this huge mistake that people actually do is they try and roll out something universally rather than rolling out where it's appropriate. What we do with dispositional mapping is recognizing which aspects are ready for Agile and which aren't, yeah? Also, there are some things which never should be Agile, yeah? I mean, Martin has been saying this for some time, Google have been saying this for some time, that Agile is suitable for fast iteration, high consumer interaction type projects, but it's actually really poor at long-term infrastructure investment projects where you need to use different tools and techniques, yeah? So leaders jump on bandwagons because they're desperate and because they've got short cycle requirements for shareholders. Your role if you're in HR or in the Agile transformation team is to stop the over-enthusiasm and get pragmatic and do things in part and don't throw away what's valuable in the old, yeah? I think that's kind of like a key message, right? There's always an interaction between grassroots level and leaders and what good leaders do is they catalyze change. Now, I'll explain that because it's key to dispositional mapping. If you want to nudge a system, you should wait until it's ready to nudge and then you just put a bit of energy in and it trips it over the edge and that's how you should see Agile. What the leaders should be doing is doing lots of small things, measuring the attitudes on a continuous basis. When the attitudes indicate that a phase shift is possible, then you trigger the Agile transformation. You don't start with it because then you set up something to fail. Yeah, and that's kind of like 101 evolutionary theory. I mean, I'll make this general point. Those of us thinking like this are taking an ecological metaphor of the organization, not a manufacturing metaphor of the organization, which means we're talking about bioengineering, not software engineering, in terms of the way we think about it. Can we take transformation more from what outcomes are desired? I actually think you can't. I think the more you set outcome, I mean, let's just take this as a simple matter of logic. Culture is a complex adaptive system. A complex adaptive system has no linear material causality. So you can't define an outcome because if you do define an outcome, all you'll get are unintended consequences or gaming. In a complex adaptive system, you map where you are and you identify the direction in which you want to travel and you remain open to new learnings on that journey. So transformation needs to be thought more about a journey from the present than an aspirational set of goals in the future. Skill v. Experience, that's actually a good question. One of the first frameworks that I've ever created in Knowledge Management is called Ashen, which stands for artifact skills, heuristics, experience and natural talent, which is a way of looking at knowledge. Now, one of the problems with agile, it's focused on the artifacts and the skills. It said, as somebody pointed out in discussion, it was meant to be about people above processes and it's become a process doctrine. I mean, safe is, to my mind, the opposite of what agility is about because it's just nothing but rigid processes and the hell with the people. So the key thing is to understand that something which is entirely focused on artifacts and skills will scale very quickly because it's high abstraction, high codification. But the reality is it's the heuristics, experience and natural talent, which will be where the value is and rigid codified processes don't deal with that. So again, I'm coming back to this both and not either or. You need process-based control in some contexts and you need dispositional control in other contexts and your skill is to understand both. So how you manage the progress of agile, cultural change, but I said I'll do it, I'll map it through storage. So I'll just basically do a story pulse every month and see whether the dispositional patterns are changing. And the advantage of that, it also means unengaging employees in the problem rather than just making them subjects. And I can identify whether the system is ready to change so the energy cost of transformation drops. Again, it comes back to this key point which I'm making and repeating. You start journeys with a sense of direction you don't try and achieve goals. Oh, and by the way, the agile manifesto was an invitation to engage in a journey not to create highly structured rigid methods. And we still haven't accepted that invitation properly. I can see another question here. Had you put an agile transformation in your presentation on agile? I mean, I'll say one thing. I would sort of stop using the transformation word. I mean, it's engendered either cynicism or rejection. What you actually do is you start to actually practice agile where it's got fertile ground. And you start to build the experience in the case and the examples that people can look at. And then you can go to the parent organization and say, look, we did this. What do you think about it? You don't say, oh, we've proved that agile transformation is wonderful. You two need to be transformed. All right? Let's say, I'll make this point strongly that the language of American Bible-Belt evangelism pervades organizational change theory. Yeah, we have a mission. We have a vision. We're preachers. People who don't follow it are sinful and have to come to the mercy seat to the front of the pocket. It's all there, all right? And you need to think differently about it. This is an evolutionary journey and there'll be some setbacks and some progress. And I walk in mountains all every weekend. It's much easier to walk along a sheep track along a contour line than to strike in a straight line across boggy and muddy ground. Follow the contours, yeah, which commit change. Don't try and impose change on the system. There's lots of... Lots of transformation. Yeah, and I'd ban the word, all right? I really would, because A, you're never going to achieve it. What you'll get is real good performance. What's the relevance of this device about pragmatism in transformation, mapping inform? Well, mapping inform networks and stimulating informal networks just makes you a more resilient organization. Yeah, I mean, it's just fundamental. And we're doing work on a big merger at the moment where we're merging the informal networks, which is actually far more important than the financial systems. And the trouble is when you get a merger, the informal networks will solidify in a hostile way. So by running a social network simulation with asymmetric teams across both organizations, we build informal networks to link and connect the group very quickly. So stimulating a mapping informal networks is just a one-on-one resilience thing that few organizations do and more should do, yeah? The disposition will be causal. I think one of the things developers need to start to do is to ask to get raw anecdotal data from users rather than have it produced in user requirements, docs, data flow diagrams, entity models, story points and everything else because this is called disintermediation. What you need as a developer is direct access to the user experience without it being interpreted. And this is also where we've been working on a complex approach to design thinking for two years now which is called an articulated neat mapping. So technology is advanced to the point where users don't know what to ask for, yeah? I mean, they just don't know what technology can do. So mapping needs in anecdotal clusters and giving that to bright developers and letting them, you know, an old DSDM technique, rather jab workshop, yeah? It's very powerful. And by the way, I mean, that's one of the techniques which I've developed for DSDM when we founded it years ago. And if you don't know it, DSDM was founded by three competitors in a pub in Cheltenham, not by X number of programmers in a fancy ski resort in Colorado, right? So this is British, not America. One of the techniques we did was called Triple 8. So we'd run a joint application design session, something agile is completely forgotten about and is really valuable, yeah? Where we had users and prototypers together in the UK for eight hours working on a prototype, constant interaction between users and prototypers. Then we threw that prototype on without the user input to a team in Mumbai for eight hours and they threw it onto a team in San Jose for another eight hours and then it came back. So this is called in Britain, Chinese whispers. I think it's called telegram or something in the States. We're deliberately introduced a mutation over a 24 lifespan. Every time it came back, the users would look at it and say, oh my God, we wouldn't have thought to that. Can we please have it? Yeah? So this high levels of engagement in directly with users without mediating layers with user anecdotes captured over three or four months of their frustrations and the very fast build of prototypes. And that's a pre-scrum technique, yeah? And we need to do a lot more of these, yeah? Innovators and laggards, well, that's a nature and nature debate and I kick a guard famously said nature deals the cards but nurture plays them, right? The reality is it's a complex mixture of experience and context and everything else. But if you're dealing with innovators, you sell differently from laggards, different from majority, this is called, we call this apex predator theory. And you need to understand that. You need to understand where you are in the life cycle as to what's actually possible. Building block for improving agile mindset in all levels. What I've just said mindset is a completely invalid concept and if you focus on it, you're gonna get it wrong. They got it wrong in every other movement, all right? What you need to do, yeah, is to actually build the informal network, map the culture, prod the system, evolve the system, engage people in the process and stop talking about it. I mean, there's a general rule and it's the more people talk about something, the more they're getting it wrong. If they don't talk about it, they just know what they're doing and they get on with it and we need a lot more people just to get on with it. Yeah, rather than getting to these idealistic excuses and transformations of mindset language. There is no valid natural science basis for the idea of mental models and mindset is a complete and at a scientific nonsense. Yeah, so can I start from a different place?