(Transcribed by TurboScribe.ai - Go Unlimited to remove this message)

My pleasure to welcome Jürgen Appelow. I'm not sure if I pronounced it right, Jürgen, right? It is. It's good enough.

Thank you, Mike. Because it's the Netherlands you're originally from, right? Correct. Yes.

And over here we say Jürgen, but people find that a bit difficult. Well, you know, it works in German, and in Austria we have some sort of German, and we'll get into that in our conversation here. But who is Jürgen Appelow, Jürgen Appelow in 24? Because I think a lot of things might have changed over the past few years.

That is true. Thank you for posing the question like that. Indeed, I was known for Managing Theta Lao and other experiments that I ran.

I am now working exclusively on the unfixed model and the unfixed company. I'm sure we're going to talk about that on the one hand. And privately, I am working on a novel that is going to be released in June.

And that is my evening project. And together, these two projects, they fill the entire week, I suppose. So I'm a writer, and I'm still a speaker, although there are fewer events these days as before COVID, to be honest.

But I still love traveling around the world, talking about organization design and organizational change and better management with fewer managers, and so on. But I tend to emphasize writing more now than I did in the past. You mentioned Management 3.0. I think, as far as I remember, that was the first thing we met about 10 years or so ago.

And that's quite a long time, 10 years, a lot of things changing. Maybe start with the personal things. What has changed for you, maybe in terms of life priorities, focus? You already mentioned the novel you're writing or about to finish.

Well, what has changed is that I put a lot of effort in traveling and speaking and training and just getting around the world and enjoying all of that. Because to be honest, I love visiting cities and going around the planet. But to be honest, I get a bit older these days.

And wiser. Not surprising. Yeah, wiser, I hope.

And as I said earlier, there are fewer events. And that's not so bad, actually, because it means that I have to focus on things that I can do at home and I actually enjoy being at home. So what has changed for me that I'm doubling down on the things that I can do while not traveling, which is more writing, design, managing a company from my home office, and things like that.

Because ultimately, I would like to be independent from travel, not having to travel the world. In order to earn an income. And yeah, that's getting better.

I mean, you mentioned the events having probably become a little bit more complicated on the circuit, probably due to the pandemic, which has changed a lot of things. There's been probably an inflation of topics, events and everything over the past years. And as far as I remember, 10 years ago, you've been visiting nearly every city in the world.

I mean, all across the globe. Yeah. Yeah, true.

So things have changed significantly. And not only because of post-COVID. All events have seen dwindling numbers of participants, I understand, not only in the agile space, but beyond.

Because there are so many more opportunities for learning and collaborating and meeting people in different ways, both online and in person. Having said that, I do see or notice a certain tiredness with the agile brand. Been there, done that.

Companies think that they cannot do it themselves. They don't need to send people to conference and to their classes anymore. And it made me think, I wrote about that recently, it made me think of the 90s when I was part of that brief bubble, when all companies needed to learn how to work with computers, how to work with Microsoft Windows and Microsoft Office and so on.

And I was fresh off university, I could program like crazy. So I wrote courses on how to make macros in Microsoft Excel and things like that. And there was a lot of money to be made in that time.

With all those people who were sent to courses. And that happened for a number of years. And then it was over.

And it was like, OK, it was not that it was not important anymore. Of course, computers were important and software was important, but companies did it themselves. They didn't send people to their classes anymore to teach them how to hold a mouse. 

And I think we are now in that same period of time, even though it took longer, that Agile wave than the wave I just talked about. And so we've seen a wave of 10, 15 years, but we're now I think at the end of it, it is still important business agility, but not something that you send people to a two day class anymore to learn how to do Scrum. I mean, that's over, I think, pretty soon.

And companies think they can do it themselves. Now, to be honest, when I look people using Word or Excel, I think sometimes, my God, you could use a course because this is absolutely terrible what you're doing. And I wrote those courses back then.

And I think it's the same with Agile. I mean, you see organizations trying to be agile and think, oh, my God, maybe they should actually send people to a two day class to learn the basics. But that's not going to happen.

So they will do it badly. And I think the glass is half full, not half empty. Better that they do it badly and then learn to do it better over time than not doing it at all.

Yeah, it's certainly not black, white, probably even until the advent of ChatGPT, you could have earned some money with Excel macros. But now with ChatGPT, it might be really over. And you just need to understand how to ask the software how to do it, what you want from it. 

I want to get back before we dive into acknowledging, by the way, one of your great products, which we just mentioned, Management 3.0, is still somehow there. Right. It is quite interesting.

I'm still doing these workshops and I've heard about Management 4.0, 5.0, but that didn't take off. So I think what you created was somehow, I think you once even said it, 3.0, that's basically it as a differentiator or as a step on the evolutionary curve. But that's just a metaphor, right? True.

Well, to be honest, I never expected it to last this long, because if I had, I wouldn't have given it a version number, to be honest. So it was sort of a tongue in cheek decision at the time to make management appeal, more appealing to software developers. I thought I should give it a version number.

But that was also a good branding decision at the time, I think. But now we are 15, 16 years further after I made that decision and the brand is still going strong. Indeed, we haven't seen Management 4.0 or 5.0, I reserved the domain names in advance, by the way. 

So maybe that's also part of the reason why that is not picked up, because we have the domains, but the team is still going strong. I'm not involved on a daily basis, to be honest, but we are in contact every now and then and I focus on other things. And what is interesting, what you put out quite a long time ago, I see coming up as a discussion on stage, for example, at Draka Forum here in Vienna that are quite well-known people on stage.

They are talking about the same topics and they're coming always back without coming out with a clear solution due to complexity. There is no one solution, obviously. But I want to get back a little bit to you personally before we dive into your latest ventures. 

And what you've been known for is being probably one of the greatest readers on the planet, I can imagine, or fastest readers, because I remember reading, I don't know, how many books per week. Well, to be honest, I'm not actually a fast reader, Mike. I do read a lot, but that's just because I don't waste time on other things.

I rarely watch Netflix or HBO or whatever. I do have a couple of favorite series, but I can count them on one hand that I watch per year because I simply don't have time for it because I prefer reading books. And I don't think I'm going faster than others.

I think I've been working on the Elon Musk book for several weeks now, which is a biggie, to be honest, his biography by Walter Isaacson, but super interesting. And yeah, it's important for everything else that I'm doing. I don't learn much from watching The Three Body Problem or The Last of Us.

I learn more from the biography of Elon Musk or how emotions are made, scientific research or whatnot. And to be honest, that interests me more. So here is a challenge for you.

What would be the three top business books you've read and would recommend that are not, that haven't been written by Jürgen Appler? The first one that comes to mind is The Invincible Company by Alexander Osterwalder and his colleagues, not as well known as the business model canvas, which sort of is the big one that they're all famous for. This is the most recent one. I think it's, aside from the fact that it looks beautiful, like most of their books, it shows how to have eternal life, quote unquote, as an organization by constantly reinventing yourself with new ideas, new internal startups that are nurtured and grown until they mature and then move from the exploration portfolio to the exploitation portfolio.

This is well described. I don't know any other book that describes it so well as this book. And it shows how it is done properly.

Unlike, for example, dare I say it, the scaled agile framework, which makes an absolute mess of portfolio management, in my honest, humble opinion, one of the many problems there. So that's one book. The other I already mentioned, Elon Musk.

I find it fascinating. I think everyone seems to agree that he is an asshole, forgive my French, but he's also genius. And interestingly enough, this often comes together in the same person.

It was the same with Steve Jobs, who also had those two qualities, according to his biography. But let's learn from the genius part, because, I mean, let's face it, he became the richest person on the planet because of multiple companies that he either launched or got involved in. And he never uses the word agile or lean, but it is what his companies do on a daily basis, much more than any others, I think.

So that's the second one. And gosh, the third one. I need to owe you.

I read so many. I would have to launch Goodreads and check the most recent one. But yeah, I don't know.

Oh, here's one, sorry to interrupt you, Mike, but How Big Things Are Made, which is a book on how the biggest projects on the planet are run well. And so think of train tunnels or skyscrapers or opera buildings or whatever. And I found it fascinating because, again, this is not a book that uses the word agile, and this is a book for, you could say, traditional project managers, explaining to them how to do project management well, but you can see how these worlds converge, because it is all about reducing risk.

What is the next step that we can make to reduce the chance that we're going to fuck up with our project and with a building that would be modeling the physics on computers, for example, that would be the first iterations of the design, which is modeling the hell out of the thing that you're going to be building before even the first spade goes into the ground or whatever machines they're going to use. And that is my argument with people in the agile community are always so go on and on about incremental delivery and incremental deployments. You don't incrementally create a bridge.

That makes no sense. You first have to model the bridge and all its physics and so on, to know that it's not going to be a big failure once you start building. So you do this iteratively and that book explains how to do iterative development on those projects, but not incremental, because some projects cannot be done incrementally.

If you make a train tunnel, yeah, theoretically you could deliver segments incrementally, but you don't have a train tunnel even if you deliver 99% of the tunnel, because you just still have a very long, a very expensive dead end. So there is no value delivered incrementally with the train tunnel. You only, you have a tunnel when it's finished.

And actually someone from Austria, Mike, said to me how they really make tunnels in Austria, which is the first iteration is making a very, very small hole from beginning to end. Why? Because they want to know what kind of rock they encounter. So that's the first iteration.

That is exactly what this book also describes. You want to reduce the biggest risk. And the biggest risk is we start digging and we end up at a piece of rock that is impossible to go through.

So literally sort of a wormhole. Exactly. Yeah.

That is the first iteration. It's not an increment because you cannot push cars through that little hole. So there's nothing delivered to a client.

I just recently saw a documentary on television where they built one of the largest AIDA ships. They're doing, you know, tourism on the sea, all over the seas. And I've never seen such a huge thing in general being built.

I mean, first of all, they need to build the whole, you know, hangar where they basically put the whole stuff in, which is huge. But it's amazing. They actually build the ship in three parts.

The parts are then put together and it looks like Lego, but it's huge. And it's so amazing. You know, they work, they work in parallel on many, I don't know how many floors.

It's so super complicated. I don't even know how you would even succeed with finishing such a thing. Yeah, obviously it swims and works.

And I imagine there is a lot of, I mean, intuitive practice in there that that's being referenced in agile methodologies, but also a lot of traditional project management, because you can't do that, you know, by just simply trying things out because that's super expensive. And another example of getting out of the black white thinking probably. Exactly, exactly.

And, and, um, well, I mentioned the Elon Musk book, the story about SpaceX are, are incredibly fascinating there. I mean, they send many more rockets into space than any other organization in the world. So they do a lot of incrementing their actually value delivery by shooting rockets into space, but still quite a few of them explode.

And, but that is part of their business model, because, um, as Elon Musk said, every rocket that explodes, uh, teaches us a lot of things about preventing the next ones to explode. And they, they do a lot of modeling and, and, uh, 3d, uh, printing and, and, uh, digital twins and so on between each launch, because they say they only want to learn things with an actual launch that they could not have learned on the ground. So of course, as a rocket is still hundreds of thousands of dollars.

If it blows up, that's a pity. It is better to learn these things while it is still on the ground. So they do a lot of iteration in between the launches, but some things you can only launch by shooting the damn thing.

And, and that is, uh, and that they're good at both, both the iteration between the launches and the actual increments of value delivery, launching satellites and whatnot. And, uh, yeah, I think that is what agile is supposed to be about. And we think we sort of made the mistake to be honest in the agile community in the very beginning to see iterating and incrementing as the same thing.

And, uh, scrum is partly responsible for that because in scrum, every iteration is also an increment. It, it results in a concrete package, a potentially deliverable software. It is there in scrum and also in the agile manifesto, by the way, several of the principles that I think the first and the third are about actually delivering software.

Well, with software, you can often do that, but with other kinds of projects, you can't, you cannot incrementally deliver a movie to a viewer. I mean, I want to see the third June movie, but I'm going to wait until it's completely done. And then I go to the cinema and then I expect a two hour experience.

I am not going to the cinema 20 times to see a five minute segment that would be incrementing. And that, that is what we have been taught in the agile community of the incrementing and iterating would be the same thing, but actually they're two completely different things. Uh, we do, we do incrementing, but with to actually deliver value and learn from the value that was delivered.

We iterate in between, that could be a completely different process in the moviemaking, in rocket building and so on to make sure that, um, well, those increments are as cheap as possible. I think you mentioned the keyword, right? This potentially, it was used, I think once they call it shippable and releasable, but it's the same potentially, right? You know, running through an iteration doesn't mean you have to ship or deliver, but you should learn something. And I think that's what you just pointed out.

I mean, otherwise the iteration is more or less like, you know, what it's here for. Yeah. Well, for me, there are two different things.

Iterating is, is, uh, um, is about, uh, experimenting and, and, uh, learning about the domain and, and, and reducing the risk that you make something that nobody, that nobody wants. Uh, it's also very nicely described in the book, Creativity Inc by Ed Catmull about Pixar Animation Studios, how they iteratively work on the story for, for one or two years before even touching computers, because they, they say, first, the biggest risk is that we make a story that people don't like. So they iterate on the story and make sure that all the characters are lovable and, and so on.

And, uh, and they don't increment. They, they, they don't make any, anything. It's just pure iteration.

Incrementing for me is an actual thing that is finished and that you could potentially give to a customer, whether you give it or not, it is there if they want it, and that's not the case with an animated movie, there's not a minute of increment available for a customer that they could download if they want it or not. So, and, uh, with software, we can do that. Indeed.

We can make it available. We can make it potentially deliverable so that they, the, the clients can say, yeah, now I would like the new update, please. And then, and then we give it.

So it's a, it's a different kind of context, a different kind of project. And that book, how big things get done. That's how we got to this.

Uh, that's a good one because it explains how that works for different kinds of, of, of projects. Now this, this already pointed to one of the probably bigger mistakes where in the agile community, people maybe have gotten to stop or an uncertain dogma or anything alike. A lot has happened in the past 10 years.

You know, we mentioned we met first time probably in 2011, 12, there's been a lot of stuff going on. You, you were a co-founder of the Agileen Europe network. Looking at, you know, what has happened in the, I call it agile industry and you might agree on this term or not, but it's widely used nowadays, looking at the agile industry, looking at the positive side, what in, in your view, if you, if you look back 10 years, what were the positive things that came out of these developments we've seen? I think the positive thing is the awareness.

Um, the fear of missing out that all organizations realize that they have to be agile because everyone else is, or is going that, that direction. That's the good thing. Um, so for me, the glass is half full, not half empty.

Even when they do things badly, at least they try. Um, even when they use bad frameworks or whatever, okay, uh, fine. That's the starting point.

At least they got started and then they will figure out that. Some things are very painful and they will try something else. I'm sure.

So I think that's the good thing. The awareness that, uh, the agile community and agile movement has created in the world. I don't think, to be honest, that there is a movement that, that has as much an effect on business in the last 20 years, because I mean, there's also design thinking and there was lean manufacturing and that was the lean startup and so on, but if I look at the impact, I think agile was, was the biggie.

Uh, and the others, uh, were nicely aligned in terms of, of thinking and philosophy, uh, and they had some other things to add into the mix. So that's, that's a good thing. But now we, uh, we realized that we have to move beyond frameworks.

Uh, I think that's a good thing. It's, um, uh, it is no coincidence. I think that the most recent, uh, thing is that have popped up are all patron libraries.

Uh, the unfixed model is not the first one that was already liberating structures and team topologies. And so shocker C3.0 and others that said, let's not do frameworks. We want, uh, just a library, a loose library of patterns.

And to be honest, I did something similar like that with manager zero, though, which was also just a collection of common sense practices without calling it a framework. Um, and, um, I think that's a good thing too. It's a sort of a new phase that we're going in.

Before you went into this area of creating a new platform, if I'm going to call it this way, unfixed, we'll come to that in a moment. You actually wrote another book shift up. Is that something the agile community has been missing somehow with the years? Like an agile approach should be talking about innovation, right? But I think only the minority was focusing on that.

What's been your learning with this whole shift up? Um, it started actually with a request of my publisher. They were quite happy with the sales of managing for happiness. So they asked me to write another book and, uh, I was, uh, working on the startup myself at the time.

So I said, okay, but then I want to write about what I'm doing. So that forces me to learn about it. So let's start about starting up and scaling up seems to be all the rage.

And then crewing up is a good thing to learn from. So startup scale up, screw up was the name of the book, uh, that came out of that. And, uh, indeed, I had a brand called shift up to go along with it, or I experimented with my own, uh, product.

And what I learned from that, cause I talked to a lot of founders and some investors and so on was this, how this ecosystem works of people having ideas and going through stages and actually the 10 life cycle stages are featured prominently in, in that, in that book, I think that was something that was missing in the agile terminology because nearly all agile transformations were focused on successful businesses in a mature life cycle stage that wanted to go faster or, or whatnot. And there's, there's, there's a place for that, of course, but those are not the only kinds of value streams or business models, some are very young, like startups. They, they go through the, the early stages of their life cycle where they, they feel more related to, uh, that they feel the lean startup terminology is more applicable to them than agile terminology, for example, and, uh, this life cycle stage thinking, uh, helped me to, to see organizations as collections of business models, collections of products and services that all go through life cycle stages and some are young and some are old and some are perfect examples of that.

I mean, see Apple, Apple was nearly dead a couple of decades ago. And then they came with the iPod, which was a big success. And then the iPod was replaced by the iPhone and then iTunes and Apple TV and whatnot, they have lots of different products and business models, and it is one family of, of, of brands and value streams.

And I think that's the best way to see an organization and those different, those different products and value streams, they could benefit from different ways of being agile, different ways of applying agile thinking, because some of them are young ones, they're, they're kiddies still trying to grow up and others are old ones and the practices should differ across those, across those life cycle stages. That was the biggest takeaway from me, from that era, for that part of my life, when I worked on that, on that book. And I see the same, I mentioned it in the Invincible Company by Alexander Osterwalder, where they explain with very methodological approach, how to manage those portfolios of ideas being born, growing up, many of them dying along the way, but that's part of life.

And, and some becoming mature and then becoming the new moneymakers for the company. And I think that has been, that was missing in the agile community, this awareness of life cycle stage. And this is super important to see that as the engine of, of your company.

How would you think now, even having your experience with these frameworks and approaches, differentiating by life cycle, what companies should do differently in order to move the needle a little bit more towards innovation when they are an incumbent, like VW, for example. I know it's a known secret that the CEO, Mr. Deese was somehow, I don't want to call it fired, but asked to leave earlier than expected because he couldn't get the software organizations inside the group. Aligned.

I have no idea, first of all, of all the, the, the constraints applicable to a company such as VW, I only know in generic terms, what is necessary for a system to survive, which is to scale out and not scale up. And we see that with some very successful ones, such as my favorite one is Hire, the Chinese company that I visited more than 10 years ago, that literally fired.

(This file is longer than 30 minutes. Go Unlimited at TurboScribe.ai to transcribe files up to 10 hours long.)