A (3:51)

Actually, that is a good point. Before we go any further, can you tell us like, because this idea of gaining value from something is not exclusive to any change, whatever that change is, whether it's AI, agile or anything. So maybe it makes sense for us to explore by analogy how you've tackled that question in your past. So in your past, how, how have you answered this question? How are we obtaining value from this change, which might not yet have been AI at that point?

C (4:23)

So this is where we get back to pool based transformation. If you can't demonstrate that by combining the new tools and the new technologies with your existing business processes in a narrow thread, business down to DevOps. If you can't show that working, you have no business introducing new tools and technologies to the rest of or your client or the rest of your business because you're doing stuff that's simply not science. What we want to be able to do is there's an old story I used to use. It's a Zen story about you get a koan, a riddle, you get a baby goose, a gosling, and you put it down the neck of an empty sake bottle and you feed it through the neck of the bottle until it's a full grown goose with its head sticking out. And the riddle is, without killing the goose or breaking the bottle, how do you get the goose out of the bottle? To save you a lot of skull sweat, the answer basically is you get a baby goose outside the bottle and you grow it until it's a full grown goose and it flies away, it's out. So if we're going to show that we get value from working with these new tools and technologies, we need to approach it this way scientifically. Let's prove it. And once we've proved it, then let's grow it. And these are things that as agile coaches, we're really good at doing. We actually have a function here and so we don't have to worry about our jobs. Our jobs are about alignment. So the neat thing here is alignment is not telling the machines to do something and they do it. Alignment is how do we get all of the people and all of the tools to work together? And by people I might mean electronic as well as biological people. How do we get these things to work together for mutual benefit or entities,

A (6:14)

actors, if you will? I really like that. There's a model that I've learned from a Finnish author, I call him a business philosopher because he writes or he wrote, he's passed away a few years ago. He wrote a lot about how to develop organizations in general. And one of the things he talks about is that in knowledge work value is created in interactions, in conversations.

B (6:41)

Right?

A (6:42)

And when we look at the problem of alignment, I think that we as humans have not been very successful at creating alignment between people. And if you just imagine now an organization that is running, you know, let's just take a number, 10 times faster. I think, personally, I think an AI native organization is probably going to run 100 or even 500 times faster. But let's take to 10 times faster. Now. If you put the already existing skills of the best humans at creating alignment within human organizations, and now you move the organization at 10 times the speed, and that means 10 times the changes and 10 times the impact of what it was before, it stands to reason that we may need to find completely different ways to create alignment than we've thought would work so far, including things like Scrum or XP or whatever that is. So what have you found from that perspective? What have you found in terms of models, thinking tools, practices that are likely to create alignment when organizations become 10 times faster?

C (8:00)

So the neat thing about where we come from is we have value that we can add that's about going faster. So the way that we're able to go faster, whether we call it Scrum or XP or something else, mobbing, swarming, all of the Joe justice stuff, all of the open book management stuff, all the throughput accounting stuff, all of these things are valuable when we can test the outcome. So if we go back to the original XP idea, we need to have automated tests and we cannot use the metrics for these tests as points that we try to optimize. We know from Goodhart's law that if we put metrics in place, people will game the system to satisfy the metrics. There is only one metric that doesn't apply to and that's Goldratt's throughput. Goldrat gave a mathematical definition of throughput in terms of operating expense plus net profit. That's what we have to maximize. That's always what a business has to maximize. So we can Measure improvements in this, we can measure the rate at which we improve throughput. The first differential of it, we can measure the second differential, and we can give names to these things. The first throughput itself, we also call it value flow. So what increases value flow? Every meaningful piece of work increases value flow. So we want to improve workflow. We're good at that. How do we improve workflow? Every meaningful learning improves workflow. So we then need to think about the flow of learning through the organization. And we can measure that as the second derivative of throughput. And since throughput has a mathematical definition, we actually have something we can bring to the table and start to measure when we introduce a tool, when we introduce a way of working, when we change the form of things. I'll use Scrum as an example. Scrum tells us there's a particular way of structuring a team. Well, we have a lot of ways of structuring a team. Let's actually test it. Let's compare mobbing and swarming versus Scrum or safe. And let's look at this in terms of value flow, workflow, learning flow, in terms of the numbers. And then we can do science on this and we can get the machines to that force. And when you start to do that, that's when you step into organizations like Tesla. If you look at Joe Justice's keynotes on the way Tesla does agile manufacturing, you see all of the old XP stuff, you see all the mobbing and swarming, and you see more, you see alignment using AI.

A (10:59)

So I see the link to alignment from the ability to surface that knowledge in a way that is actionable. I mean, you call it the throughput of learning. Right. Like it is way to describe it. And I really like that approach of using. You called it scientific, I call it experimental, meaning we do something with an expectation, we measure the results so that we can compare with the expectation and then learn and iterate. Right. And I think that Joe's work, Joe Justice's work is also very much in that, even before he joined Tesla. So check out his work with Wikispeed, which is an inspiring project of creating

C (11:44)

an open source and fast, because FAST is where a lot of the Wikispeed ideas came from. Joe did work with the FAST guys, and that's great, but I don't want to take away from the guys who don't necessarily get credit for that stuff and need it.

A (12:00)

Yeah, absolutely. And FAST stands for so that we can link people to the right source of information.

C (12:07)

Oh, goodness, now you're stretching my memory. Let's put it in the show notes.

A (12:12)

Yeah, we'll definitely put it in the show notes. It's an agile like approach, so I'll make sure we link that in the show notes so that people can go and check it out. And it's funny and also insightful that the idea of speed comes into this and even throughput, which is not raw speed, let's be very clear about this because throughput is not about measuring movement, it's about measuring impact of movement. In fact, the whole on the market theory of constraints is a great example of shaping the speed to what the system can hold productively and then changing the system so that it improves the overall. And here comes the word throughput again. And it's funny how this idea of speed and also implicit in throughput comes back over and over again because it is for me an indication that we are constantly struggling with the idea of scaling. And here it's not scaling size, but it's scaling impact. Right. Like even the whole idea of throughput accounting is exactly in this perspective, that we need to shape the system in accordance to what is possible at that time and then evolve the system so that we have a better outcome and speed and outcome when they work together. I think this could be great guiding perspective perspectives for anyone adopting agile anywhere.

C (13:45)

I would take a step back from that if it's okay with you and Pasco, Are you familiar with the pirate metrics?

A (13:54)

Pirate metrics? R. Yes.

C (13:57)

Yes, ARR. So what we did with XSCALE is we started to look at these as market constraints. If you're going to acquire a market and then you're going to activate it, you're going to retain it, you're going to get referrals from it, you're going to have revenue or return from all of the above. You can look at these as potentially the constraints on your value flow. And so we know from the law of constraints that one of these is going to be the bottleneck. It drives me mad that here we are 25 years after the dawn of Agile and if I walk up to a business stakeholder and I ask what's our market bottleneck? They don't know.

A (14:51)

Oh, and bottleneck itself is not a word that is commonly recognized. Exactly.

C (14:55)

What if we say what is our market constraint? So then they will sit down and optimize or try to optimize their intuition about what's going to make things go fast, what's going to increase throughput, what's going to make learning flow through the organization. All of the words we. They'll prioritize things without being scientific about it themselves, without actually understanding that if you have a constraint that's limiting throughput and you don't know what it is, then your priorities are bullshit.

A (15:25)

Yeah. And also if you try to be

C (15:27)

as quickly as possible, and if you

A (15:28)

try to be faster in a non bottleneck location, you're just going to create more problems.

C (15:33)

No effect. Exactly.

A (15:35)

Peter, thank you very much for sharing all of those insights. Unfortunately we're running out of time for today, but we still have two great episodes to come everybo. We'll all see you tomorrow.

B (15:48)

Hi there friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work just like you. The first track is AI in organizations where practitioners show what actually works. No hype, just AI that makes your Monday better. Happy Monday everybody. And then we have the people track honest conversations about putting humans at the center of how we work and keeping them there. And third is Agile in construction. And yes, I really mean brick and mortar construction. Lean and Agile. Actual job sites. Field leaders removing waste. Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game studios ship without burning out Agile Inside the Creative Pressure Cooker over the years we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast. And this year we're making it easier than ever to join. You can register for free and get access to the summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner pass and get immediate access to last year's keynotes from Jurgen Apollo, Gojko Adzic and Mirete Kangas right now, even before the Summit starts. So grab your practitioner paths and start learning today. Head on over to Bitly Forward/Global Agile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit ly GlobalAgile 26, all lowercase, all one word and 26, that's the numeral to and the numeral 6. I'll see you on the conference floor.