Peter Merel's Agility Narrative on learning flow & responding to market change

Peter Merel, founder of xScale Alliance, in his Agility Narrative talks through the xScale's approach to agility, and enabling organizations build capability to respond to market conditions. 

He talks through how learning flow in an organization is key to responding to market change. This is something that 95% of agile transformations do not achieve effectively, according to the longest and largest survey in the Agile world, "The state of Agile Report". 

Peter is highly entertaining, with great stories of the birth of Agile and XP.  Enjoy... 

0:01 Welcome & Intro

1:21 Peter's early engagement with XP

3:49 The birth of Agile (before the manifesto)

5:01 then Snowbird happened and I was busy...

5:21 The story of to xScale

8:35 Why is learning flow so critical?

11:00 How to improve learning flow by looking at constraints?

12:14 Learning flows as a product

13:03 Importance of market constraints

13:51 Onboarding people

15:33 "The Progressives"

17:00 using trust to scale teams

19:04 Responding to market conditions

21:01 Changing market conditions, design and patterns

24:32 "How do teams make decisions?"

29:19 Villains are also heroes

30:33 Changing the game - game theoretics to reward mutual benefit

32:28 What at stake for us?

35:22 Noble intent and the wrong track

37:04 Call to action - key learning constraint, starting with an open space

40:39 Pattern language used to have a conversation

42:21 Ongoing process, 3 month change increment

44:40 The threats and opportunities are often same

47:31 Getting ahead - pirate canvas

48:11 As business agilists, who are our clients?

49:08 xScale Alliance offering's

50:50 The importance of these conversations

Transcript

martin: [00:00:00]

 Welcome to the agility narrative podcast, I co-host, we hold this space, so as a community, we can listen to leading change makers and enterprise agile leaders, talk about their personal journey with agility. With each narrative, we hypothesize that we have more insight into part of the whole. Hi, Peter. Hi Martin, how are you going? It's good to see you on this podcast. Peter is Australia's longest serving agile is credited in the original XP book created the first enterprise agile framework in Ninety Nine. In 2015, Peter founded X Scale Linux of the Agile World.It's recognized by Gartner as a marketGuide for enterprise Agility. Peter has also three decades of transformation and delivery programs. I love how you package information. Peter Game without Thrones Pirate canvassed business bingo and you have a strong global team and you're making an impact in the world of opportunity.There's so much Topic here that we could talk for many hours, but I'm hoping that we could focus on your personal journey and dig a little bit into something that you had said in games without Thrones meeting about learning flows, being the core to creating a learning organization which is core to excel. So can we go back to your roots as the longest serving agile?

peter: [00:01:21] 

I was all about software as far as I was concerned. I wasn't particularly interested in in teamwork. I spent the first 10 15 years of my career as a programmer. I let people call me an architect because it was a handy way to get things done. The approach that I wound up taking to agile teams and agile organizations is still sort of founded on that idea of systems or ecosystems. This so in 96 or something like that, I got involved with the patents community, which sort of blossomed on the first wiki in the world of the C to keep that word, Cunningham started. So I was enjoying what we were doing there. I edited about 2000 pages of that wiki. This guy, named Kent Beck, turned up and Kent started talking about this weird stuff called extreme programming. And I thought this was all nonsense. I put up a bunch of challenge Questions and Kent, as he always does cut through Them like a knife through butter. So I decided if he can deal with these questions that easily, then I've got to try this for myself. But  the  only as far as I knew, because scrum wasn't even a noise. So anyway, when I wanted to get involved in extreme programming, it was only one exp project in the world and it was in Portland and I was living in San Diego and I like the beach. I'm particularly interested in visiting Portland, so I thought, Well, okay, I think I understand enough about what Kent saying that I can try this locally, and I started going along to interviews as an architect. And I think it was about the 12th or 13th interview. I found a really great hiring manager at General Motors, Mark Anderson, and said, that sounds wonderful. Let's do that. Okay, good. So I wound up kind of coaching by stealth, the second  XP program in the world and the actual manager, the development manager, had no interest in doing things this way, but we managed to get things done for about nine months before I was thrown out. But happily, in that nine months, we were able to demonstrate an awful lot of goodness and I'd been going out to lunch with The VP of A startup that was in the same building that we were working in at General Motors blossomed, and this start up website, as it was called, became a multinational and life was Good. Well, I got put on the spot at Web sense, so I wound up designing the first agile team in the world, and that was ninety nine and it worked very nicely. So I took it along to XP 2000, which was the first agile conference in the world. It went over very well. We had about 200 attendees. We ran it competitively and backed with the coach for one team and Martin Westphalia, Frank Westfall and Frank Stein won. That conference was really where Agile began as a word because Dave Thomas brought along a pamphlet from rational, rational, unified process. And they said, Well, if we don't win, no one's buying extreme anything. If we don't rebrand this immediately or as soon as humanly possible, we're going to lose control of this has just become another corporate buzz word, and there was a stand up in the Mediterranean at the end of that conference. Martin Fowler  took a picture of it. There were about a dozen of us Ron Jeffries, Kent Beck, Alistair Coburn, Ralph Johnson, both Dave Thomas and me. A couple of other. Notables,

satish: [00:05:01] 

So sowing the seeds of fragile must have been very Exhilarating experience, Peter.

peter: [00:05:07] 

No, it wasn't a depressing, actually, because because six months later, Snowbird happened. I was busy with start ups, so I didn't go. And it's got to me.

satish: [00:05:21]

 So from there to Setting up this, what were the triggers that led you to start something like a scale, which is such a daunting Project

peter: [00:05:31] 

Like any daunting project? I had no choice. I was interested in getting things done, and as far as I was concerned, XP was the one true flavor of agile was just where I was at the time. I kind of think a scrum is just XP minus minus. There's a lot Of things that were taken out to make scrum. I started being an agile coach. We've been doing this for long enough. You start getting offered bigger and bigger gigs. In 2010, I coached a transformation for a group of 330 at Australia's largest insurer, Insurance Australia Group. And that worked, and I had a call about about a year later from a gentleman who had fired me in the Commonwealth Bank of Australia. You could have knocked me over with a feather. This was five years later and this guy calls me up. And he says, I really liked the ideas that you were talking about. I didn't think we were ready, but I think we might be ready now. Would you come back and would you be principal coach and strategist for a transformation of the bank? Do we have permission? He said No. Ok, well, I think that's worth a try. Then it took about three years from that conversation to when I shared a stage with the group CIO and he declared Agile is one of the five pillars of this bank's future. So fifty thousand person bank. So it was the Biggest transformation Project that I'd ever had anything to do with. We'd had to invent a lot of things, particularly in product agility and business agility, because they just weren't any patterns in the literature that the code What we needed. So I thought, Oh, Well, that actually worked. I mean, well, that generation of the transformation worked, of course, this endless generations of transformation of big businesses. And usually, if you do succeed, you can rely on the next transformation. Screw it up for you. But anyway, I thought, Well, I've got some stuff here that I could sell, but I had no reason to sell it because I'd just done this big, successful transformation. So I thought, I'll go and do another one. It's much easier money to do that than to try and brand something and come up with a business model for the thing. I thought, OK, I'll go. And there were four big banks in Australia. I'll go and do this for one of the other banks. And six weeks later, I was fired for doing what he asked me to do by him. He thought agile was micromanagement, but he thought that micromanagement meant a Spotify model. Unfortunately, he was really very unhappy with the fact that I'd been trying to do this thing for him that he had asked me to do And Blackened. My name in Sydney is quite a small market when it comes to agile coaching, and I couldn't get work. So I basically had a choice because Australia is a very geographically distributed place, so I could basically Move a Very long way or try to commute a long way. Or I could try and come up with a way to take this stuff, brand it and sell it. So it turned out that was easier.

martin: [00:08:32] 

Thank you for that story. So let's start talking about your agility narrative. Had a few questions to sort of set the context. Recently, during a Game of Without Thrones, you had said X scale is fundamentally about enabling learning flops. There are so many topics we could explore with an X scale. Why is learning flow so critical to enterprise agility?

peter: [00:08:56]

 We would Hope that enterprise Agility or business agility would improve the flow of value to the market. That's really what we're being employed to do, and improving value flow in traditional Agile is basically

peter: [00:09:12]

 A matter of prioritization. We should be prioritizing the things that are going to have the the biggest impact on business throughput. There are a couple of problems with that don't actually measure business throughput in most businesses, even though there is a nice concrete definition we get from Eli Gold Rat. People are stuck on cost accounting, so that means that they don't really think in terms of market constraints. If they think in terms of cost accounting, when they're making decisions about market constraints, then they're going to wind up in a very bad place. You would hope that every piece of work we do would accelerate the flow of value to market. So great if we can improve workflow, that's going to be an accelerator for value flow across the whole organization. No matter what we do, then anything we did as far as workflow is concerned with raising value flow improvement. And indeed, that's really where the first generation or two of agile played. We like to improve workflow by having stand ups and retrospectives and having the team think about the way they're working and what they can do to improve the way they're working. But if that learning is confined to little teams, then they don't share that learning. If the learning doesn't migrate up the hierarchy or across the hierarchy or both to be able to influence the way that other people make their decisions, then the flow of learning through the organization is constrained. If we can work on that flow of learning, if there's a way to improve that, then we're going to be able to accelerate workflow across the organization, which accelerates value flow across the organization, where you could think of learning flow as the second derivative of value flow or a business throughput. You can even measure it that way. So how do we improve learning flow? Well, we have these things. We call transformations, change programs. These things are supposed to improve the way that people work across the organization. Problem, then, is that most of the time you don't think of those things in terms of constraints. For folks who aren't very familiar with theory of constraints, there's always one key constraint multiple bottlenecks. One of those bottlenecks is the key bottleneck is the constraint. When we look at our transformations, we don't try to understand what is the constraint. We don't prioritize the constraint. We try to push change across the whole organization. If we were thinking about how to do this properly, we would think about all of these things value flow, workflow learning, flow in terms of the theory of constraints. And to do that, we would have to prioritize all of them, each of them in a different way. We'd have to think breadth first. So I began to realize that really a transformation is treating learning as a product and the organization as the market leader.

martin: [00:12:14]

 That's really insightful. So tell us About learning Flows as a product and how You designed It. Scale to support that Model

peter: [00:12:24] 

X scale began as product agility method. It began on program in Commonwealth Bank of Australia called coaching. It was an idea that was very far from the mainstream of the way that bank did its business. We're talking 2012, and it was an incredibly influential program, both in terms of the bank's approach to digital channels, but also the bank's approach to agility. It won the award for Best Program in the Bank. It won about a dozen external product awards. It became a digital channel that was estimated at being worth something like four billion. I coached it for its first 15 months. When we did this program, we had to come up with a different way of approaching project agility of breadth. First way to do it with one that was based on Prioritizing not At a story level, not even necessarily at a feature level. But what we needed to think about was what features are going to open to market constraints. So I've used this phrase a couple of times and you could just think in terms of pirate metrics, acquisition, activation, retention, referral and return, the acronyms are. It's why they call pirate metrics. If we can do that, we can start to say, well, OK, based on our understanding the epics that are involved in this Program, how can We generate a set of features that we think might open this constraint? We can take exactly That approach to a transformation Program. We have to acquire people in this program and because if we do that. And will wind up with a bunch of resistant people pushed into the program who are usually not adequately motivated, and this is where most transformations come unstuck. If you wind up in a place where half the people that you've said are doing agile are actually just doing the darndest to use the language and not actually work that way, then you're going to wind up in a place where you can't get the outcomes you're looking for, and the outcomes are always about improving value flow. I say that, but there are An enormous number of businesses that try to do agile without ever even thinking that it's best to improve the flow of value. They don't understand it as a tool that's going to have a profound change on the profitability of their business. It doesn't do us any good to hand out certificates to people if it turns out they're not moving from the role of a change participant to a change leader, then turning around to other people who have trust relationships with them and saying, Ha ha, let me help you over the hump. We're going to do this properly and return in a learning context, I think is stuff that enables further learning. If we don't look at those as our bottlenecks and say which one is the constraint, if we can't look at this breadth first. There's no way that we're going to get a good outcome for a transformation. It's just a nonsense. So if we think of learning as the product, then we need to be able to measure throughput when we bring this product to its market. We need to put numbers on these things and we might do some good.

satish: [00:15:29] 

That's a beautiful articulation of our transformation change and the importance of learning and the throughput and the KPI. So, Peter, so in the change narrative, who do you consider as a protagonist?

peter: [00:15:44] 

That's a good question. We would need people to have to want to change. You always find some progressives in the Business, but They won't win if the rest of the people in the business don't have a reason to change as well. But the idea is we want To get this progressives and we Want to bring them together, just a few people. First, we have to locate them because most of the time change leaders or sponsors, they don't really understand whether the progressives are and usually those people are not very interested in really doing that. Or we might have an idea about change that they would like. You want to bring them together. Business design, delivery, DevOps. A dozen people. 20 people, something like that. The most progressive People in the business and Get them working in a coherent fashion. Money flow, product work flow and value flow, which is to say, business agility, product agility and DevOps. If you can bring them all together in a coherent way so that they actually can prove the pudding well, then you can do a very simple thing you can say, Well, that worked. We can hold an open space and Show that it works so that everybody who comes to that open space will be able to see their work, and we can then use the trust relationships. These people have to find some other people to come and join in with them. We can split that initial steel thread capability right down the middle, and we can backfill with the next most progressive people or people who trust those progressive people and those people who come in. Then we participate in the next iteration of change or incremental, if you want to call it. I like the idea of sort of a three month increment of change. I think it actually works. So the first time we try to do things like this, 2010 at IAG, we used that kind of cadence. When those people come in, they will be learning from the people Who are already doing it properly, who they trust. They won't be learning from external coaches, scrum masters, a bit of learning from people who they know, they understand the business. And so they will follow their lead much more naturally, much more easily than they would follow an external consultant. It's not time to say we want to get rid of the consultants. Consultants are still very useful as servant leaders, as designers of the program, as Troubleshooters accelerators. But what we really want is for the change participants to learn to become change leaders so that then after another three months, we can split and double again. We really don't want to repeat the experience we had with that initial increment. And what we have to bring people up to speed from scratch. What we want is to keep on leveraging the people who have already come up to speed. That's the way that we can get change to happen with a minimum of resistance, a Minimum of disruption, a minimum Of expense and a minimum of risk. So this transformation is the protagonist. I think the protagonist is the people who are leading the change and they're all different levels of the business. So it's not an end. Vigil person, we can confirm that we had that person. It's more a matter of seating, tomatoes and growing growing the next bunch from cuttings.

martin: [00:19:05] 

What is your theme for your agility narrative? What would that be and why would you pick that theme?

peter: [00:19:13] 

Well, when I was trying to come up with X scale, I thought it was a nice name. He started coming up with all Kinds of clever ways of Explaining things in terms of the letters of that word, which I did. So and the funny thing was I kept thinking, Well, surely it must be missing something because I'm just basically taking letters from scale and trying to to hang principles on the principles of exponential throughput. I thought, Aha, we've got something that hang the X on.That's good. x could be simple, simple design. That's good. A B autonomy in Alignment and or see

peter: [00:19:52] 

Was continuous throughput. And so I started doing it like that. So in terms of themes, triple loop learning with the L ecosystems thinking, OK, great, I've got a bunch of principles, I guess I would suggest that the fundamental theme In X scale is responding To changing market conditions. But if I have 20 seconds to put this over to someone on a board or a see suite, and what I'll usually say is OK. The largest and longest running survey in the agile world, the state of agile report for the last six seven years in a row asked the same question. And basically, I've asked as agile help your organization respond or adapt to changing market conditions. Ninety five percent of their respondents, you are almost all adults saying, no, this is appalling. But when we came up with the manifesto responding to changes, one of the fundamental value propositions over following a plan. Ninety five percent can't do that. We failed. We completely failed. So when it comes to business agility, to me, that's the definition of business. Agility is responding to changing market conditions. So we live in the current world is nothing but VUCA. So if you can't do that, your business is doomed. It might not be doomed tomorrow, but it's certainly doomed over time. So I would think of learning in this context. I would think of exponential in this context as well, because it's not just exponential growth, it's exponential decay as well. You might want to call it a logarithmic curve. I don't care. You're still the same shape. If you put your growth in your cake together, you wind up getting a bunch of sigmoid curves and next scale you try to stack those. Which is to say, we want to understand where the greatest potential for throughput improvement is. We're talking about simple design, which was that was borrowed, that phrase from Kent Beck. But with the next scale, we look at this as a way to approach design Breadth first and Experimentally test in design thinking. Interior design thinking by itself is not enough. We fold in set based design as well, because if we can't do that, if we're not motivated to do that, then we're going to wind up making bad decisions because they won't be adequately informed. No one gets it right the first time, so we need to perform these experiments to eliminate the parts of the design space, the design Universe where Value isn't. If we don't do that work of eliminating those things, then all the design thinking in the world isn't going to get you to the most valuable part of the space. So set based design is critically important. And then we also fall in original idea of merciless refactoring of simplification As A fundamental design process. If we do design thinking that no bubble in design thinking that simplifies aren't so, but responding to change if we don't continuously approach this first design process. If the cost of redesign is prohibitive so we can't Respond to change, we're doomed.Continuous throughput Accounting well,We expect the constraint to move as fundamental to the theory of constraints. We have to be measuring these Things and there's Lots of things we can Do to look At where the constraint is in that context. But responding to change is baked in autonomy in alignment. We have this stuff we call leadership as a service. It's a protocol to generate servant leadership. We can talk about the way we motivate this stuff, but basically the structural model that goes with this and Camelot model, it's really about simple patterns that enable you to respond rapidly to change the for learning to flow rapidly across your teams, across your hierarchy, up and down your hierarchy. The fundamentals for this are well understood. Robyn Dunbar's work is fundamental to what we do. That's not done by number. It's the Dunbar series. It's got to be baked in if you don't do that. If you don't scale in that context, you can't respond rapidly to changing market conditions. Learning we talked about before ecosystems thinking goes down the same path. That's been a mutual benefit. We have to look at the market as an ecosystem. If we look at it as value streams, we're trying to accelerate single values. And people miss the Potential stream right next door to that one. That's better.

martin: [00:24:32] 

I think you've talked about five or six different collaborative techniques for how people can relate to each other in sort of a relational way. How does learning get impacted By those techniques?

peter: [00:24:45]

 We have to start with the way that a team makes its decisions. So leadership as a service is a fundamental challenge to command and control because it approaches the way a team makes its decisions. And it's a very simple change. If you think about it, the way that we typically make decisions in teams is a bit mad because what we do is we say, well, there's one person, whether we call them the team leader or the manager or the scrum master or the owner or whatever that is, we call them, the one person is going to make The decisions and Everybody else will try to influence That person. But ultimately, if they don't make a good enough case or if there's some political reason why they can't get their case made, then then we'll get a bad decision made. And there's no feedback mechanism. There's nothing that leads to leadership buy influence. It's all leadership by authority. And if you have a team where that works badly enough, we become so disempowered they don't even try to bring the right influence to decisions that they actually have the Expertise to influence. So the idea with leadership of the service is simply to say what? We're going to use a very simple balance of powers technique. And a lot of people have been scrum masters have done this. If you ask, let's say you're playing planning poker, of course, these days with no estimates at play planning poker, but we still get together and refine our backlog into similar sized pieces, which amounts to very similar kinds of decisions. But I'm just going to use playing poker as an example because it's got numbers in the numbers of easy to talk about. So let's say you've got three people in your team that say this story is a three three people who say it's 13. Well, most of the time, if you do multiple iterations of planning poker, you will eventually get people so worn down that they'll either give up on influencing or they'll be convinced by each other's arguments. Either way, you get Down to a single number. Hooray. Most of the time, it's an awful lot better than the estimate you would have got from a single individual. So that was good. But sometimes it doesn't work. Sometimes people dig in their heels and I'm telling you it's a 13. I don't have time to explain everything in the world about database architecture to you. Nobody else in this team understands database architecture, but I'm telling you it's up to our team. Should we overrule that person, should we not do the needs of the many outweigh the needs of the fuel, the one, the all Star Trek thing? We need to weigh them and balance them. So here's how we do it. We simply say, OK, if there is a particular topic that this person is a recognized expert on, we're going to have one person who is directly responsible for recognizing their expertise, directly responsible individual recall that recognize their person. We typically call them a speaker, but you could call them a manager or a leader. Be recognized directly. Responsible individuals hold Apple idea of our eyes. Every agenda item has to have a dry or work item in a cemetery. So all we do is the directly responsible for executing whatever decisions made about that item. We simply say, OK, if everybody else in the team is unanimous, they can Overrule the D-R.I For that item if they can't get unanimous. The D-R.I is to decide, and we have a time limit on when the decision is going be made. That's it. And the neat thing is it means we always get timely decisions. Everybody is motivated to play nice as people might support them when it comes to their own decisions, and they are also motivated to influence so we don't get that leadership by authority thing. So if we do that in our individual teams, OK, that's good. We've moved to a place where our teams are making better decisions, but then we have to have them take each other into account, which is where we have quality circles and then we'll have quality circles and the teams are all too small to make decisions. Next level. So how do we get those decisions to be informed? We have a way of rotating people Up a level. It can take turns. We do this by quality circle. That's where we get into Camilla. So the intent of all of this stuff is to try and improve the way learning flows both within a team, across the teams, using the quality circles and then up and down the hierarchy using the rotating council.

satish: [00:29:09] 

As long as everyone considers it as a learning exercise, it's a smooth flowing process, right? But that's not the case. Most of the time. So you talked about the protagonist as the change leader. You talked about the change narrative as well. On the other side of the protagonist are the villains who are the villains or who are the antagonists in your perspective, in the change narrative.

peter: [00:29:38]

 If we think in terms of heroes and villains. We're probably missing the wood for the trees. That's not to say there aren't villains, but it is to say The villains in other

peter: [00:29:50] 

Contexts than change are probably heroes. That guy in the guy or girl in the corner office that causes so much trouble and they play all these nasty games and they don't tell anyone the truth. They do things that are good for their career, But everybody else suffers. They go Home on the weekend And they had their dog And they kissed their spouse and they tuck their children into bed and they read them bedtime stories and they have a barbecue for their neighbors. And they're wonderful people. Just the salt of the Earth. Everybody loves them. They love everybody that just great love. When they go back into the office on a Monday, the rat bastards, because they know that's the way to win the game. So we have to change the rules of the game. And it's simple. The game theoretic of organizations is simple. We need to reward mutual benefit. We have to hinge peoples Rewards on Business throughput. This is open book management. This is stuff that is also not rocket science. Very simple patterns. The Jack Stack and John case came up with most of this stuff in the 80s. No one listened to them. They've been making some Progress Inc magazine piece. Publishing a Typekit lobster sometimes do. But when it comes to business agility, we have to get the reward models right. People have to go OK. If we increase the throughput for the business As a whole, then I'm going to get my bonus. Or then people start to think about their work differently. If we can reward them in terms of equity as well, they start to think as owners, they're all thinking, how can we increase the throughput for this business? I would really like to be able to buy a bicycle for my child. Why don't we try to make some experiments with that? We need people to be Able to Share their ideas and their learning about the best ideas to win. Quoting Steve Jobs. So the way that we Do this has to Be the fundamental. If we think that everybody has the potential to not be a villain, to actually be acting Heroically in the contextOf improving the flow of value to market while the flow of learning across the business. They simply need a motivation to do so. Just stop being a rat bastard if the only way you can win is through mutual benefit. You will try and make certain everybody wins.

martin: [00:32:13]

 You've got the most innovative approach to basically turn villains into heroes.

satish: [00:32:18] 

Every villain is Already a hero in their own mind,

martin: [00:32:21] 

For sure. We don't associate villains with people. It's just a way to have that conversation about what needs to change, what is at stake here for your clients, for the industry if they don't take this Action to create heroes From villains. They don't adapt to the market.

peter: [00:32:38] 

I think it's a more fundamental question what's at stake? Everywhere we look around the world, we see failing systems of all sorts. And obviously, we can look at the governmental systems and go, Oh my God, what's going on now? They've forgotten everything we learned at the end of the 20th century. They've gone back to the 1950s. It's crazy. Why is it crazy? Because the systems are broken, but the same thing applies. To the corporations, most corporations have the same kinds of political problems. If we look at what we are doing as a species, we're cutting our own throats. And it's very obvious we're doing that. Climate change is an artifact of capitalism. Capitalism isn't bad. It's just broken. We can fix it so that when people think about, I kind of think that I'm not going to be able to get any business throughput if everybody's dead. If we start to actually think that this is really our mission as adults, I'm not kidding. We really are here to save the world from itself. Changing market conditions. There's nothing that is a bigger driver of changing market conditions than climate. I'm not saying this is all about climate. There's any number of stupid things that come out of the way. Humans make bad decisions. So if we go okay, every villain is a hero in their own mind. If we can improve the way that we make decisions in a team, in a business stream or program, in an organization, a corporation. We stand a chance of making good decisions for mutual benefit for everybody. I'm not saying that's going to happen automatically. It's not. It's not a matter of, you know, we all do transcendental meditation. And when a million people do it, the world will be saved. No. We have to do this work intentionally, but we have to start somewhere. So we began 20 something years ago with little software delivery teams. Now, business agility is enough of a recognized quantity that businesses are actually saying they want. This x scale has some conversations going on with some of the world's biggest consultancies, biggest accounting firms. That's amazing.But you know, this was a twinkle in an eye. Five or six years ago, if we can use those relationships to actually heal the way that the world makes its decisions, even if they're still made for commercial capitalistic purposes, at least they'll be made rationally, then maybe we can actually survive. Maybe our children can survive. As far as I'm concerned, the business we are in started out with very noble intents. If you look at the agile manifesto. Those guys weren't fooling around really for its time. It was an utterly revolutionary statement. I remember whenI read it, I was physically Really super annoyed that I had skipped going, but it was so obvious that it was it was going to change the way we were doing things. The trouble is an awful lot of framework. I started realizing, you know, we could actually make a bit money out of this stuff. I don't want you to tell all of the stories. If you go and there's an Uncle Bob Martin Talk he Gave, I think, 10 something years ago called the land at Scrum Forgot. If you want to know where the bodies are buried, go and listen to to that book. But these days, it's become a joke. I think most people are aware that the idea of training someone to be a coach is a nonsense. Coaches need scar tissue. You have to actually go and get that scar tissue before anyone should be called a coach. You can't give them a certificate and say, that's going to do it. So if we start to think that the way we have been doing things as an industry is corrupt and we're the people who are coaching the businesses of the world, it's no real surprise that we're corrupting them and they're not able to respond to changing market conditions. If you strip it back, bring it back to basics to fundamentals, Value Flow, workflow learning flow. These are things we can measure. These are things they can do science on. If we could do that And we can improve the way the world works and hopefully save ourselves much,

martin: [00:37:04] 

I think, to start to close this Competition. You're talking to a group Of key stakeholders wanting to move their organization forward, and honestly, they feel stuck. And you understand you have an empathy for their position. Tell us what's going on and what would be your call to action to that.

peter: [00:37:23] 

When you work with an organization, you really want to understand what it's constraint is, its key learning constraint. And if you talk to the people who are hiring you, they don't understand it. They can't tell you what it is. They may trust you enough to engage with you, but they don't Understand their own problem. And usually the problems they stand have more to do with politics than anything else. So the first thing you can do is say, Well, why don't we try doing some really simple things to try and understand the problem? So holding an open space, we usually we have a thing we call the Seven Samurai campaign, which begins with an open space with the theme of How do we make this business the very best business of its kind in the world? It's a lovely theme for open space. You have to use the word agile at all, because if you say that theme, no one will dare stay away. Even the people who are violently opposed to change one reason or another will turn up. They don't want to be seen as the people who would oppose this business becoming the best of its kind in the world. So an open space Like that, it's a great place to Locate the progressives I mentioned. It's a great place to find out the range of bottlenecks, the the whys, theHouse, the Walls. If we think in terms of impact mapping, it's a lovely way to hear it. And if we hold one with it out, how do we make this business the best of its kind in the world? Then we will naturally have everybody turn up the resisters and the progressives. Resisters will tell us about the problems, the reasons that it can't possibly change, the things that stand in its way, things that really would need to change for progress to be made. The progressives will propose all kinds of solutions, most of which will be impractical or simply not on point for the constraint. It's a great Way for people to hear each other and to begin to actually think about mutual benefit and working together in a different way. It's a wonderful technique, simple technique. Leadership is a service we Massimino as an equal alliance coach who he introduced leadership as a service to a group of 13 VIPs in a Colombian bank credit banco. He said that these 13 vice presidents had never been able to make a decision together in the previous five years. He'd consulted to this bank previously. They hadn't been able to.They were

peter: [00:39:59]

 Locked up. They were, like you said at the start of the question. They felt they couldn't make progress and suddenly they were able to make decisions together. Suddenly, they were able to get learning to flow at that level.That led to Massa running a Game without Thrones and so on and so forth. Simple techniques, but they're focused on whatever the constraint is in the learning flow. So if we take the part metrics and apply them to learning flow, usually we discover that whatever the constraint is, is something that is a simple problem that has a simple solution. So its scale is the pattern language. If you think of a pattern as a solution to a complex problem in a specific way, then we're trying to bring a Toolkit to apply To these sorts of problems. We're not trying to have a framework and say you must do it the X scale way or otherwise. Well, excommunicate you. What we want To do is not a conversation going, including everybody who's involved in that kind of stuckness. And sometimes this technology has nothing to do with politics or change. It might be stuff has to do with the way the organization is coming to market or whether the way it's competition is heating it in the market doesn't really matter. You have to focus on the constraint because we're not coming with a one size fits all framework. Do this and you will be you'll be wonderfully adaptive and agile, and all of that stuff will just magically happen. That's because we're trying to do it intelligently. We're trying to do it experiment. We're trying to do it in a way where we can get a cheap, small scale change to happen and test whether that actually solves the problem. So if we do things that way, then we wind up with a change program That is quicker And cheaper and easier. And above all, safer in the sense of less risky. And we can do that With an organization that's doing safe. We're not saying that safe is wrong. There's lots of people who would like to say that some people can't say it because it's politically something it can't be heard. We're not saying scrum is wrong. It might be. It might be wrong in some contexts.Any of The agile Pattern languages that Underpin these frameworks has A Utility. What we want to do is pick the right tool for the job. Right tool makes the job easy. So if we work with a group of stakeholders that feel stuck. What we want to do is we want to understand not just what is the current stuckness that's fix that problem. But once you open One constraint, Then another bottleneck will become the constraint. So this is an ongoing process. It's not a process that has no end. The progress in this process should be reviewed on a regular basis. So what we typically do when we engage with client is we say, Okay, well, we're going to Do a three-month Change increment. We're going to work with you in that there's three months. So whatever we collectively regard the constraint as being. And then at the end of the three months, we're going to run an open space to look at the effects that those changes have made on not just the people who are involved in the change program, but everybody else because it doesn't do us any good if we make one team win in the rest of the organization goes down the tubes. So what we're going to do then is see whether you then have any further appetite for engagement with us. It might be that you feel that well, with an extra three months, we would be able to really put the last nail in the coffin of whatever the villain is or whatever the problem is. Or it might Be that you have a completely different change objective. A different bottleneck becomes the constraint. Or it might be that you go, Well, thank you very much. We got what we wanted, and if we have any further problem, we'll give you a call. That's a healthy relationship for a professional industry to have with their clients because they're never overpromising and they never overdelivering. They're never asking people to pay for years of their time. And then, oops, we made you safe. We didn't say that you were going to stay in business. We will solve the problem. So the neat thing with doing that as a coach is you wind up in a situation where you can build the price, you can get paid ahead of time. You don't have to worry for the whole time and materials, the billing cycle, all of that nonsense that goes away. But from the point of view of the client, they are not overcommitting and they're saying that they're getting growing capability.

martin: [00:44:26] 

That there are choice at the end Of that Engagement and you haven't built a dependency.

peter: [00:44:31] 

I think everybody Has a choice. And everybody has to prove the pudding as they go. Exactly.

satish: [00:44:36]

 That's great. Peter, the very wonderfully put. So it's very clear that there are great advantages in targeting agility. It certainly helps the leaders navigate and lead in the uncertain world. We are living in the cover now from Australia in twenty twenty two. How do you see the threats and opportunities the world faces as agility seems not optional anymore? And how can these principles help drive a better course of a future for us and the future for the planet?

peter: [00:45:13]

 In many ways, the threats and the Opportunities are the same things when we think about changing market conditions. We have new energy technologies. We have AI coming into a place where it's actually useful, not mature by a long stretch, But it might Mature very quickly because it's being applied to itself. So as a feedback loop, there we have new food technologies that have come out quickly, new medical technologies that are coming up quickly. And I'm sitting in a Tesla at the moment, though, there's there's a whole huge change to very well established industries that's being generated by all of these things. If we think of a Tesla as a confluence of A.I. and energy technologies, if we Think of it that way. Well, it was something that anyone Could have done. Tesla began as a startup, but Tesla is actually in general. Musk's companies are incredibly good at doing this idea of getting ahead, finding the the next curve and funding it to the hilt, and often they will fund things where people go. I don't really understand the use of that space. What is this really good for? Once the the industries are established in orbit, once we have an ability to start mining first near-Earth asteroids in the Moon and then spreading out into the rest of the Solar System, the industries there will will be so remunerative it will beggar the imagination of people in the 21st century, but it's an awfully long play. Why would someone make such a play? Well, life extension technologies are coming up to speed very quickly. All of these things are moving so quick. The business as usual scenario is that most business analysts think about simply fantasies. The real threat is that we weren't grasped the nettle. These changes are happening, and we're going to have to respond to them. That's the reason that Tesla's market cap is presently greater than not just Ford, not just General Motors, not just Chrysler, all of them put Together. And this is a company that makes very small number of cars compared To their petrol Cars on the road. But anyone can see the writing on the wall, so getting ahead of that stuff means a different kind of business analysis. And this is where we talk about product agility and breadth first continuous basis. But we begin with something as abstract as a pirate canvas because we have to understand the frame before we try and paint the picture. If we fail to do that and we borrow down some apparently remunerative business stream, we will Miss the real Opportunity that's sitting right next to it. Often the best move is right next to the worst move, and you don't have to look at too much of the history of business to see that. So when it comes to our approach to this is agile. We have to stop Thinking that software Development teams are our clients. Our clients are the corporations. Our clients are the big businesses who are being left in the dust. And so our clients are also the startups who are disrupting these big businesses and our clients, the small to medium size who find themselves in marketplaces that are moving so quickly. They are simply being left behind. So there are opportunities all over all of these businesses at every scale of business. What we need to do to bring change us, we have to have a coherent business agility offering first before we try and do anything, our delivery team DevOps mode and to bridge that gap. We need a product agility offering as well as those two offerings. X Scale Alliance is basically in the business of business agility training courses and product agility training courses. We have some of our coaches working on doing an XP based, AI based and cloud based DevOps course. There's already plenty of people in that in those waters, and as far as I'm concerned, that's not where we can disrupt the industry. What we have is in the context of business agility and product agility, and now we are in a good place having quoted those courses to enable agile coaches to bring them to their clients without having to swallow the ocean by taking on a framework. As far as we're concerned, where we're trying to provide Coaches with a

peter: [00:49:58]

Training capability, not a bunch of trainers With the collateral And with the techniques and with the support, they need to be able to get the outcomes that they want with their clients. This is why we talk about the Linux of the agile world. We actually Use Creative Commons licenses to support all of this stuff. We use the Harmony license for a contributor license agreement. So all of these licenses are all About making certain That the coaches are able to make a business with their clients that they can accelerate without being dependent on someone called a trainer. But without having to sell somebody certificates. So the purpose for all of that is to get the outcomes that their clients need, which is all about adapting to changing market conditions. That's the game. That's where agile is today.

martin: [00:50:50]

 Thank you, Peter, for your insights and for sharing your story. You've taken us from the learning Flows to How to adapt to changing markets, and you've really illustrated the criticality of innovative thinking and product agility as part of that. Thank you. Thank you very much.

peter: [00:51:10] 

Absolutely my pleasure. I'm sitting in a car that could not have existed 10 years ago. The rate of change is such what we do in these conversations Is actually pivotal For the way the world develops. At least it will be if we do it right. If we do it wrong, well, we won't. Here in 10 years, all 20. Thank you very much, Peter. Great pleasure to meet with you.