moderator: 0:00

Welcome to the scrum.org community Podcast, the podcast from the home of Scrum. In this podcast, agile experts, including professional scrum trainers and other industry thought leaders, share their stories and experiences. We also explore hot topics in our space with thought provoking, challenging, energetic discussions. We hope you enjoy this episode.

Dave West: 0:25

Hello and welcome to the scrum.org community podcast. I'm your host, Dave West, CEO, here@scrum.org in today's podcast, we're talking to Dr Mick Kirsten. This is not Mick's first time on the podcast, but for people who do not know Mick, I'd be surprised if there's any listening, but if you don't, he is the author of project to product, an amazing book that was part of the low metric revolution and the shift towards product operating models for many organizations. It was also and I think more importantly, the founder of Tasktop, a lifecycle integration and data company that was acquired by plan view. Now, full disclosure, I actually worked with Mick at taskstop as the chief product officer. He persuaded me to leave a lovely, cushy job at Forrester Research, take a pay cut and join a small startup to change the world. Yes, he is that persuasive, and yes, also, the conversation was in a dark bar in Berlin at 2am when I decided to move I just want to get that out there. And that would be a very different podcast if I actually shared that story. So instead, the reason why Mick is on today's show is about his new book. Yes, it's really exciting. First Book was awesome, but this book, its title is output to outcome, and explores the fundamental shift that organizations need to make to take advantage of AI and deliver more value in the modern age. Welcome to the podcast. Mick,

Mik Kersten: 1:56

thank you Dave and thank you for reminding of those memories of the dark underground bar that was, that really was a great moment.

Dave West: 2:02

It was, it was all the best things happen in dark, underground bars in Berlin. But that's not we're here to talk about, unfortunately, output to outcome seems to continue, where project to product really left off was the motivation to write the book, driven from your experience of applying the ideas for project to product and then seeing what broke next, or was it something else?

Mik Kersten: 2:25

Yeah, it started as that. So what happened was we'd had basically several years of data of organizations applying the product operating model and really usually within an Agile transformation context of some sort, and we saw what was working, what wasn't working. And then this whole AI thing happened right kind of late 2022 I got very involved with building out an agentic framework. I was Chief Technology Officer at plan view, and we realized, okay, we needed to actually, really pivot our product offerings, as well as the way that we built our software around all this amplification that was now possible through AI. And then this, something occurred to me, which is looking at the study data that we had from the state of the project to product industry report, I was starting to see that organizations that had this more modern way of working this product operate model, which really is right around agile concepts end to end, not just agile teams, but a more more agile business and more agile ways of working across the organization. Those organizations, I realized we're going to have a much easier time applying the amplification of AI than the organizations that still have these laggard, waterfall, water scrum fall type ways of working, and that's because what we saw in the data across three dozen organizations and over 3600 value streams is that around 8% of the end to end time of delivering value to market across this enterprise cohort was spent on development teams. Right? Your Scrum teams actually delivering value. So if you now make those Scrum teams five times more efficient, you're actually not delivering any more value, because their bottlenecks are upstream and downstream of the teams. I realized this looking at it from the data itself. And then, of course, this is what was unfolding over the course of those years, which is that I was seeing some organizations leverage AI very quickly in terms of what they were actually able to deliver, whereas others were just making teams faster and not really actually evolving their products, their offerings to the customers, and not really innovating faster. And so what started out as this initiative that I had of really and you and I chatted about this at an above ground bar, if you recall, whatever we

Dave West: 4:40

did

Mik Kersten: 4:40

we did Dave and I have our best conversations at bars, it would seem the most productive ones. But you and I were discussing. I was like, how do we how are these organizations still so stuck? And I was really looking at, okay, how do we do more? You've done a lot of work since then on, on agile product operating models, which is amazing. And I started writing that. And I was really, okay, this is a piece of the puzzle. You. But these organizations are just not wired at all from less on the technology side, more from the actual organization design side to leverage the amplification of AI. So it started as a product operating model thing and kind of an A palm closely a palm related thing. And then the book really shifted quickly to okay, we need to look at some other more fundamental things around how organizations are structured,

Dave West: 5:24

and that fundamental difference is driven by this, by the title, really by this idea of outcomes rather than outputs, is that the fundamental sort of like narrative or thread that brings all of this together?

Mik Kersten: 5:40

It is, I think. And this was a pretty profound realization for me. People in our roles, Dave, the things you and I used to work on, right? Like I will, I will never forget when, Dave, I think you are actually in my office, uninvited, telling me that I had to prioritize things. And I was just very disturbed by the whole concept, because I had multiple product initiatives I wanted our teams to be executing on. Dave, you were Chief Product Officer, and you decided this was the perfect time to have that difficult discussion with me and teach me about prioritization. So we've spent our and I'd spend a lot of work, of course, in my career on developer productivity. You've spent a lot of work on your career and help organizations build and structure around software and innovation and agility, and really all of that work that us, our colleagues, our industry peers have been doing over those last two decades is around the scarcity of basic development and resources, right? All of a sudden, what we're seeing, and what was pretty clear a few years since 2022 is that scarcity is now not going to be scarcely anymore. We're going to have, as these models evolve, as the way that agents leverage the models. We're going to have this almost unlimited ability to produce software. Most of it might be slopp, but it'll be there, right? We'll be able to crack the code. We'll be able to crank out the code. The thing that I used to love as a craft much as I love building Legos when I was a kid, I loved building software in my 20s and 30s and some of my 40s. And of course, now a lot of us are getting reinvigorated by what we can do with Cloud code or codecs. So it's becoming fun again. But the bottom line is that that thing that was the constraint building the output, and that was actually really fun. It was it's fun building Lego, it's fun writing code is now no longer going to be constrained. It's just going to be approximated by the cost of tokens or electricity. So all of a sudden, organizations maybe not today, but we'll be able to crank out 10 or 100 times the code that they could before, and build much more software. And it The question then becomes, is that actually delivering any value? And of course, the concept of an outcome is organizations should have some kind of value metric around their employees, their market, their staff. And we really need to shift the operating model around managing the constraint of outputs, of building features and applications and those sorts of things, and really shift it to having a management system and mechanisms that monitor and provide a feedback loop around delivering outcomes, and really whether those outputs are connected to outcomes. So that's the core thesis.

Dave West: 8:06

And it's funny, because I've been talking to a lot of organizations about AI adoption. I just got back from the Netherlands, spending some time a very large bank there, and there was a question about, How do we justify the value of AI, and you there's a lot of work. Codex is a good example of this. GitHub is doing a lot of work on this as well, and it's about, you know, how fast you're closing tickets and how much code you're bringing into into a release, or whatever it doesn't seem to be. They seem to have lost the plot with respect to value, because ultimately, adopting AI, the ultimate value of AI is that we are delivering more value to customers and to stakeholders and to users. Ultimately, we need to be doing more of those things. And to do that, we need to really rip the band aid off and start aligning better to that and and I think that's what when I read the book, mate, that's what I really got from it, how you can build value streams to align to outcome more effectively. And the other, the second section of the book, I was blown away by because it actually gives you a practical way of adopting these ideas, which I thought was amazing, but our listeners haven't had the benefit of having a pre release, pre release copy, like I did with big signs saying, do not put this in an LLM, which I didn't, which means I had to actually write my quotes for it anyway, but which is so much hard work now. But anyway, the that my the listeners haven't had this opportunity. So could you just take us through the key points in the book and the sort of like the journey the book takes the reader on?

Mik Kersten: 9:49

Yeah, I'll do that. I just want to reflect on something you said around the how organizations are looking, whether they're getting this benefit from Ai, right? Like the latest thing that the past couple of weeks, and. Been, let's measure people's productivity on how many tokens they consume. And that's that's been something people been saying for a while. Clearly, it's something

Dave West: 10:07

you've

Mik Kersten: 10:08

adopted internally. Dave, sorry. And before that, like, how many agents we hear this all over, right? How many agents you build, or how many lines of code the agents are producing? And so I think we've got this. Organizations have this knee jerk reaction of jump, jumping on a new thing. This is a huge product of the amplifier. And then measuring the things that are really easy to measure, which tend to be output metrics, right? Or, in the case of tokens, consumption metrics, that obviously are very nice things for Nvidia to have and the labs to see grow. But the questions are those things a proxy for productivity that leads to customer outcomes, that leads to real value, and that, I think, that we saw this, of course, with in the last two decades as well, right as people were looking at developer productivity, people the metrics that were being measured were being lines of code produced. And of course, we realized with a delete, it's much better to actually have a fast feedback loop that tells us did those lines of code we wrote produce customer value, if not, let's pivot and have this nice hypothesis testing loop. And so at the whole core of output to outcome is this, basically, it's called an outcome loop. So it's just a formalization of this feedback loop that assumes that it's no longer going to be a scrum team or two that's going to be delivering the value. It'll be a scrum team, let's say of several people, but many agents, so all of a sudden that one team is going to be able to deliver much more value, right? Maybe it'll be 50% more today, and maybe it'll be 10x more in two years, and then 100 times more, and maybe that team, the shapes of those teams will evolve, and we can't predict all of that yet, but all I think the core assumption in the book is we will be able to deliver 10 or times more value with a single team, whereas that used to take something that would take 10 teams. And of course, this will continue scale, because we'll want to deliver all that value and all that software, and so at the core of the book is this notion of an outcome loop that we need. We actually need a fast feedback loop on whether the outputs being built by the humans and agents are producing the outcomes that we want. And that outcome loop is really simple. It's got inputs. The inputs are strategy and budget. So that's really what you provide to that team. It's got outputs. The outputs are the activities and artifacts that teams produce. So the features and apps, they deliver, those kinds of things, services and such. And then outcomes. And there's, there's customer outcomes, which any business or government organization, in the case of their customers or citizens, should be trying to drive, and employee outcomes. So the outcome of actually puts the people, the humans, building the stuff, on the team as a first class entity. And what we want to do is actually drive that loop as quickly as possible and apply the theory of constraints to that loop. And that this is really the other core principle of the whole book, is that the theory of constraints, which we all know and love from Lean and Agile. It'll continue to apply in the age of AI, it will continue to apply always, because any complex system has a constraint. Dave, in your earlier review of the book, you mentioned like these can be multiple interacting constraints. I did make those edits. It does go into that level of sophistication, which you pushed me into. But really there is, at any single point in time there's going to be going to be a fundamental constraint, and it's no longer going to be no longer going to be in the case for most teams, the ability to deliver, create code and outputs. So that constraint is actually going to move is going to be your planning process. Is it going to be your feedback process with your customers? It's going to be somewhere we want to find that constraint, remove that constraint, and then use that to actually deliver outcomes more and more quickly,

Dave West: 13:41

it's interesting. You mentioned that the constraints have changed, and historically, the career that I built and you built was based on the constraint being the software development or delivery, getting to done, releasing code, testing code, deploying code. Back in the day, it was you're not quite that old, but CDs and discs and stuff like that, you get these books sent out when you get to actually deliver them to be pressed, and those constraints have changed that now what I see in most organizations is there's two major constraints. One is around governance, because there's a level of trust that is changing because of AI and risk and trust, those two really interesting elements. And then the other constraint that I'm seeing is innovation, or the in a very scrum terms, the backlog, the product backlog, the fact that if your teams are delivering super quick, then maybe the backlog gets run down. So how do you fill it with stuff that's valuable for the organization and strategic? And it isn't just stuff the changing this for no real reason, and they're the two biggest constraints that I'm seeing. And. Do you see the same? Did your sort of data started to pull that apart a bit?

Mik Kersten: 15:05

Yes, anecdotally, I absolutely have come across those, and we're at the point right now where there's more pressure on planning and the strategy, because the teams are capable of delivering so much more, and those parts of value streams have not quite adapted to this new pace and this new speed of feedback. Now, the point of the outcome loop is actually just to be much more higher level and generic than that says, Wherever the constraints are, you need to look at the constraints. Maybe that's for some organizations. For example, when they've, let's say they've solved the innovation constraint, which I think it'd be very hard to solve, right? Because I think there'll be ongoing to your point pressure on now innovation that's strategic and customer centric and so on. No one's most organizations have not innovated at this rate, right? Let's say innovation stops being the constraint. Maybe budgeting process will be the constraint, because now you actually need to redeploy budget to the value streams that are working much more quickly than you did before, right? And kill things off that look promising much more quickly. We're seeing this with, and this is just very coarse and an odd example with Sora, right? Like it looked

Dave West: 16:08

like

Mik Kersten: 16:09

something that looks very promising, but when you've got other value streams that are more promising in terms of what they can deliver, you'll actually need to kill things off much more quickly. So I think what we see from organizations that are good at this is the way that they look at this portfolio. They know how to look at the constraints, address the constraints, and if they can't address the constraint. So let's say that the cost constraint of in this case, using this example of source, too high, given the potential that it can deliver, you actually just kill off that particular product line. So that's the point of the outcome loop. Is to give us a tool. And by the way, the whole the book has many models. As you saw, it's quite dense with models. Each one of them is meant to be whiteboarded with a marker in a non embarrassing amount of time, so you don't have to draw too many lines and boxes at the whiteboard or virtual whiteboard. So that's really the point of the outcome loops. Is it like, where is our constraint given? Now it's no longer the teams. Let's identify that constraint. Now there's another key aspect to it, which is, and I think, as we've seen through the adoption and popularity and importance of Scrum, it's important of teams, importance of teams, and that outcome loop is really all about the team, right? We I think what we see in terms of what good looks like in organizations that are leveraging AI effectively, is that team is empowered to find their own constraints, to address their own constraints, and it really owns their outcome and value stream. And so at the core of this operating model and this notion of outcome management is the fact that the team needs to be empowered to own the constraints of their outcome loop and to resolve their constraints. If their backlog is too big or they might not have they're at the point where the codings become easy, but there's much more design and iteration with customers they need to do. They need to be able to bring on that talent and potentially those AI resources or solutions, to be able to more quickly iterate on design. Right What we're seeing right now with these AI agents, it's possible for teams not to just try out one set of screens or one mobile applications, to try out three or four in parallel, and all of a sudden, to your point, that puts much more pressure on the backlog, on innovation, on design and so on. But really the goal, the outcome loop, is that the team owns that end to end piece.

Dave West: 18:19

Obviously, that's very refreshing, because there's a lot of stuff in the press now that teams are dead, the idea of having teams is no longer needed, because you just surround yourself with a collection of agents and you can do anything because of this monetization or multiple accessibility, commoditization of knowledge, as it were. So it's interesting that teams still exist, and it's also interesting in it. This is a immediacy, as I say. I was at a bank last week, and what they're interested is that was they've been applying AI technology. There are big users of Scrum. They've actually reduced the number of teams, but kept but actually some of those teams have increased in size in terms of people, because the value stream now is not like 20 teams working in this one big value streams, big room planning. They're using LPN, lean portfolio management. They're like this has created a level of complexity and coordination that is almost impossible to manage because of AI. We're producing so much stuff. How many meetings can we have? How can we I just can't consume it as a cognitive overload, as it were. So they've reduced the number of teams. So what would have been 12 teams is now one or two, and that empowers that team to make those decisions. So it's interesting that you emphasize the importance of teams, because I'm starting to see that which is the opposite of what a lot of people have been writing about.

Mik Kersten: 19:50

Yeah, I think people are very excited, I think rightly, about the power of what one person can do right now the first billion dollar revenue or valuation

Dave West: 19:59

with three. People or whatever, or

Mik Kersten: 20:01

one person, right, or either way. So I think all those things are it's possible now to contemplate those things. I think we'll start seeing some of those things. But I think it in the end, first of all, there's this fact that I don't know you and I have been part of smaller companies and highly effective teams, Dave and things are much more fun and sometimes frustrating but rewarding when you've got a great team. That team might be two people, it might be a small number of people. It might be a full size scrum team. It might be, I know Jensen scrumg is entire leadership team of 60 people, or whatever it is now his direct reports, but it's those teams make work fun, right? And I think it's obviously very rewarding to be managing fleets of agents because of the things that you build, but you just don't get that same, I think, kind of invigoration from that in the long run. And I think more importantly, we'll still be in the scenarios, whatever the agents are able to do do for us that this is gets out of one of the core things that output the outcome, which is, while that cognition, intelligence, all those capabilities, improve the intentionality to build things, the intentionality around achieving interesting new things, around creating organizational and business results that help you get promoted, help you get a nice bonus and go for a nice vacation in your family, Those are the things that are still uniquely human and in the end, it's these groups of human intentions and human groups that achieve really great and interesting things. It just now they'll be amplified by an even larger number of agents. So I think while individuals will be able to do much more, teams are going to be key, and they're absolutely key. And the foundational element of what's an output outcome, I think we know the amplification will happen. We know there'll be hybrid human and Agent teams. We know like there's quite a bit on autonomous value streams where it's all agents running things. So output, the um, is actually compatible the model. The models are compatible with a one person team. It's just much more sort of one person organization with a bunch of autonomous Valley Stream is just obviously much more boring world, but we It doesn't assume we know the exact shape of teams. So how teams will evolve? How many designers versus developers, versus product managers? And as those skill sets evolve, how many will be on each team? But that fundamentally will continue to

Unknown: 22:18

have

Dave West: 22:19

teams. Another thing that's really interesting about this conversation is, ultimately that you're still highlighting the fact that human beings will provide judgment and motivation or incentive to create the solutions and the outcomes that that we really want. So do you think, though, that one of the key challenges, one of the hurdles that most organizations have, is aligning those things that ensuring that everybody's making judgments and choices and driving those things all in the same direction, because When you're working super slowly. It's easier to get everybody in the same direction. Ish, because you get the time, you either beat them in argument or wear them down with just sheer persistence. And people slowly move in that sort of sort of direction. Do you think that alignment is going to be around the right outcomes and to allow humans to make the right judgments, etc. Do you think that's going to be a, I don't want to say a key constraint, but certainly a characterizing constraint. I

Mik Kersten: 23:30

absolutely think it will be. It is a key constraint. Go back to your that bank you visited, that kind of the complexity of what's being produced. We're increasing the complexity of the organization substantially by throwing a bunch of agents into it, we're increasing the complexity of what's being built by building much more of it. So we're in basically, we're used to a level of coordination cost between all of the human leaders and people in the organization now, leaders and agents in the organization, and it was barely manageable already, right? The coordination cost on, on, let's say, redefining a new strategy for a company, just the number of meetings that tends to cause is massive, or for redeploying a new agile product operating model, or any of those sorts of things, right? These are these really high coordination cost activities, and depending how you look at it, we just increase the coordination. If we don't change the operating model itself, we're going to increase the coordination. Increase the coordination cost by 10 or 100 times, and it's happening today. So I think that's organizations are seeing that as the constraint. I think the only way through it through some kind of scalable model of empowerment of empowered teams, right? Because the only ways we really know how to deal with complexity is by encapsulating complexity. And so the there's this really key theme, and of course, biased by my work and software architecture and open source and so on, of modularity in the book is that we're really good, all the way back to Legos, right? We're really good at working with complexity when things are building blocks that we can compose and. Then the interactions between those building blocks are manageable, so they don't all fall over. And so I think what we need to do is to manage this new complexity, because it is a complexity explosion, and when you can actually build all these additional things, and it's amazing. But in the end, that alignment between strategy, budget, delivery teams, customers, changing customer sentiments. Because, of course, all of this is being exacerbated by the fact that the market's changing too, right? So it's like it's a super disruptive within a company, and this explosion of complexity while you're dealing with changing market complexities, which is why I think we're seeing so many people in leadership positions actually working much more now rather than before, right? Things have gotten more chaotic, not less. I think the only way through this is through managing that that new complexity is to encapsulate that complexity where teams really own key discrete pieces of what they deliver, the outcomes they deliver for their portion of the organization. And all of this is really loosely coupled. Means you've got as few dependencies in this scalable structure, which in the book is called the outcome tree. And of course, you've got dependencies, you've got graphs, you've got informal relationships, all those sorts of things. But the more you can encapsulate on a team in terms of these complexity domains, the easier it is for that team to move faster. And so there's these. The book has these shifts, so I'll give you one of them. So there's the kind of the three models. There's a product operating model, because that's still foundational. The outcome loop model, which we talked about. Now I'm finally answering your second question, and the outcome tree model, or whatever question that was, what the book is. So there's three core models, and then there are these seven shifts. And so one of the and each of them has a has its model. So one of the shift is to move away from Matrix structures to modular organizational structures. So it's called matrix to modularity and all that matrix thing that organizations did by putting in these second operating systems with agile and so on that. It says, unwind that. Make that. Make that agile operating system. Your first operating system, right? That's the one that's go around delivering outcomes to customers. And the model there, it's very simple model. It's just called the independent action model, where what you're doing is making sure that each team, with its whatever its leadership structure is, whatever its set of agents and autonomous value streams under it is, can act independently without asking permission or having all this coordination to, let's say, drive its backlog and innovation its own innovation agenda for its customers. So I think the only way this stuff scales is by providing that encapsulation, modularity and independence for the teams.

Dave West: 27:32

So we've been preaching that for a long time. Matt, yes, I don't mean to be rude, but one of you know, the reason why water scrum falls still exists. One of the reasons, there's many reasons, is because of the inability of organizations to really empower small groups of people, relatively small groups of people, up to 100 it's not that small, but to really focus on a clear set of customers, values, whatever, and so what do you think is going to change that actually allows this? And I don't mean to be derisive here or negative, because I think the book and the ideas are really awesome. And the first time I've ever seen all those ideas brought together in one way with a which is something new and creative with a fabulous narrative that connects it. So I applaud the book. However, I worry that these things are hard and organizations ultimately don't trust, don't empower. They do and don't all at the same time, because realistically, you could get through all the governance processes and do exactly what you want, as long as you had a story that you did it by. So there was, like a fake kind of model. But ultimately, organizations don't like empowerment and don't seem to trust in that way. What do you think is going to change?

Mik Kersten: 28:57

Yeah, and Dave, I would say that's appropriately negative. I think, because I think that the challenge you and I shouldn't be laughing, because I think it's I was at one point, it's like, what's I was thinking, what's the point of writing this book there's gonna be, like, I was disappointed at getting that project to product industry report data that we did,

Dave West: 29:14

yeah,

Mik Kersten: 29:14

how these are not full laggards? Like, we were looking at a bunch of large banks, these sorts of organizations with ton of spend, how is it possible that they still have this much water scrum fall inside them? Because really, that 8% I talked about is a water scrum fall pattern, right? It's that waterfall planning, budgeting, approval and so on. And then, of course, a lack of sort of DevOps, automation and other platform engineering

Dave West: 29:39

to

Mik Kersten: 29:39

make things easy downstream. So the, I think one thing is, so I asked myself, is there's, did we somehow? Because I think a lot of actually, let's back up just a little bit. I think a lot of organizations do have these ways of working. And so we did see a lot of successful organizations, right? And we see that technology natives do have. Have their planning process and their delivery process are this one feedback loop, and from that, they have the speed of decision making and so on. And then this works at scale, right? It works at Amazon scale, Microsoft scale. We know these things scale, so we have the positive examples. The frustrating thing is, why do so many organizations not do this kind of empowerment? And my goal with project to product was to say, okay, agility and lean were never around just making teams Agile is around making the whole thing agile. And that worked to some degree, not to another degree. And I thought, okay, was there something off with that guy, with that guidance? And because I actually in that matrix, the modularity that that chapter that unwinds the messy metric structures that organizations implemented. I did see a common pattern, and this does come from good intentions, but a lot of organizations took scrum said, We're gonna make Scrum teams implemented that, or the ones that I know got confused and read the Spotify memo, did squads and crews and so on, and yeah, that

Dave West: 31:13

doesn't matter.

Mik Kersten: 31:14

They were trying to do, yeah, so that happened, but they never actually did the harder step of changing the org chart, so they implemented a new operating model as an overlay over an existing one,

Dave West: 31:27

yeah, and these people reported into other organizations with different incentives, with

Mik Kersten: 31:33

different

Dave West: 31:33

alignments, and that ultimately undermined and you were on three teams to be

Mik Kersten: 31:38

Yeah, and you be at some point, you might have Two managers, and then the regional manager, if you're based in Europe or New Zealand or something. And that complexity actually went it took something that worked, which is Scrum teams and at scale and scales, and it actually, I think it impeded it, because it introduced this, back to this, like whole coordination cost issue. So the but and organizations that didn't do that really made its primary opera model worked. Now we do have to keep in mind there was a lot of guidance out there on this right a lot of consultancies were saying this is the right way to do it, because it's faster to create an overlay structure than to actually change your org chart. You even have, I think great thought leaders call this whole notion of a second operating system, is have your hierarchy, but create this overlay network that's much faster moving and so on. So I think those experiments just that didn't work. And so in output to outcome, I decided to be just more bold and prescriptive, and say, if you need to make your kind of this agile system the way that you deliver the primary that has to be the org chart. And if it's not the org chart, stop reading. Or I'm sure I've put it more politely in the book, but they've

Dave West: 32:50

already bought the book, so he doesn't have to worry about

Mik Kersten: 32:52

them reading. So I think the we've got enough of these practices. And you actually mentioned another key thing, like you and I have seen this over and over, how, let's say there's a better implementation, where it's less of a messy matrix, but the incentive structure of the leaders and executives doesn't match the what the teams are doing. So there's a whole section. I actually was surprised I ended up getting to this level of depth on how you incentivize leaders in a structure like this, and if you don't again, if you have two incentive structures, or there's MBOs and there's outcome based or incentives, it just won't work. So I tried to be bit more specific on the things that we've seen work and not work, because I think too many of these organizations have taken the easy first steps of, let's try out the Scrum teams, let's give them agents and so on, but I've not made the organizational changes. So this is a book for those willing to make those organizational changes.

Dave West: 33:46

I was, yeah, and I'm so glad you, because when I read it, I was like, this is profound and incredible, but it's not a compromise and and I see so many people adopting these ideas in a very much a compromise that ultimately, though well intentioned, ends up destroying the benefits and just creating more complexity and mess. Okay, so I could just listen to you and ask questions for all day, and we have done that in the past. We nodded a bar next

Mik Kersten: 34:24

podcast would be four hours from a bar,

Dave West: 34:26

yes, and we've closed a few in our time, I have to say. But our listeners are sitting there, hopefully they've seen the link to be able to pre order. They had a link to the website. Lots of great resources there. The what? What would What do you think they should take away from this conversation and from like, why they should take this quite aggressive approach to this change in this new AI driven world? What should be the sort of three things they should take away from this conversation?

Unknown: 34:59

Yeah.

Mik Kersten: 35:00

Yeah, I think the first one is, I think the good thing is, with a level of urgency, everyone's leaning into some version of empowering their teams at every level organization with AI. And I think the first one is that the organizational structure and operating model need to change to be able to leverage that and basically decomplexify it. So I think number one thing is there isn't a path through this where you do a halfway change and you don't change the operating model. So I guess that'd be number one. Number two is, and it's there's this whole notion of empowering teams if, again, this won't work unless you're able to empower those teams end to end. And yes, to your point, Dave, people have heard that before and not done it, but I think if you actually start measuring the ROI that you're getting from AI and from that token spend, you will see that the teams who are empowered are actually delivering more outcomes to your business and customers than the ones who aren't. So I think that second one is just back to that whole point of empowerment, but it's not optional. Now things are moving too fast not to do it, and that's really back to your point, right? It's like before we had time for that alignment. Now there just isn't time when you're producing that much more, when the feedback loops are that much faster. So if you don't create, and it's not enough just to say empowerment, and this is really one of the other core things that put down, you have to have mechanisms for empowerment. For empowerment. If a team and value stream doesn't have the ability to decide on how this is actually a core principle, given a budget and strategy, they should have full autonomy on what outputs they create, right? It's drive customer outcomes, yeah, whether it's 10 mobile apps or one screen or one chat interface, whatever it is, like it's around again, as long as it's aligned to a strategy. And there's, of course, there has to be a feedback loop with that strategy. So the second one is this empowerment and autonomy for teams. And then I guess the last one we touched on this a little bit less, is just how this because we're talking about teams and scaling structures and empower the autonomy on teams is what that new role of leadership is, and in supporting that so I think the third one is redefining the various levels of team leadership and support of exactly with the things we discussed on this podcast. Right is making things around that empowerment, the team structures, enabling

Dave West: 37:21

incentives alignment, yeah, etc. That's great.

Mik Kersten: 37:28

Because the other, sorry, the other thing that could happen say, so what's with large organizations? Is it going to be a set of 100 teams reporting to one CEO, or are we going to have to have another structure on top of that? And I think that interesting is how we create an effective leadership structure to harness all that work that teams

Dave West: 37:48

can do, and we're going to open another conversation here. But do we need reporting in the same way as we used to have? We do? We do do, or should it be more like VC and a portfolio of companies, a VC can have many portfolio companies within its portfolio. It has some mechanisms to manage that, QBRs or whatever. Is it something more like that? Is it more? I think the notion of reporting and the notion of organization structure, the way that we've had it is very steeped in a system that has basically been outgrown, I think, and flatter, faster, empowered organizations are definitely the way. So maybe each of these teams really almost runs like a little organization to some extent, or these teams of teams. Maybe it's around product. Maybe it's something slightly different,

Mik Kersten: 38:46

yeah, and I think that's directionally right now, this is another huge topic, right? So that we just opened up. But let me just touch on that briefly. So in that model where we really are these portfolios of products and value streams, like things that teams are building, and I think the VC example is a good one, there's questions, do you need a questions, do you need us? Is that a completely flat structure, in some cases, that'll be sufficient? Is to make that a flat structure or and this gets back to complexity, and domains of complexity, do you do what large VC firms do? And you have a structure, you have this large portfolio, but the healthcare parts of the portfolio have has one set of partners and entrepreneurs and residents helping the healthcare part, and then the AI part has another one, and the Bitcoin part has another one, and so on. It's what are the minimal structures where you can be supporting the kind of complexity or industry or market domains underneath the top level of the company,

Dave West: 39:39

and it depends on what the role of leadership is coupled with the diversity of the complexity, the diversity of the things that the organization's doing, I think, but really interesting. Oh my gosh, I could carry on talking about that. We can't. Unfortunately, we've reached the end of today's podcast. Mick, thank you for. Spending the time today,

Mik Kersten: 40:01

my pleasure, Dave, that was a great talking to you.

Dave West: 40:04

It was, yeah, mind blowing, as always. And thank you for listening. Listeners to today's scrum.org community Podcast. Today, we were super lucky to have Mick Kirsten talking about his upcoming book and the research that spawned it, output to outcome, which is exploring that fundamental shift that organization organizations need to make in taking advantage of AI and delivering more value in this modern age. We just scratched the surface of the topics that this book discusses. So I do recommend buying the book and delving into it. Also, there's a fabulous website, and guess what? There's loads of prompts that he helps you craft so that you can explore some of these things yourself, which is always fun. If you like, today's podcast, please subscribe, share with friends, and of course, come back and listen to some more. I'm lucky enough to have a variety of guests talking about everything in the air, professional Scrum Product thinking and of course, agile, thanks, everybody. Scrumm on.