Episode #043 // Is agile dead? // with Dave Thomas

In Episode 43 Dave Thomas, co-author of the manifesto of agile software development, joins us to discuss the strange turns the term “agile” has taken.

From a general frustration in software development to a global industry of consultants and coaches, agility has been used as both goal and tool. At times, it takes religion-like dimensions – whereas it started as a way to empower individuals in doing work well though guiding values and sound judgement.

We digress to explore which parts of agile software developments make sense in an organizational setting and how organizations could look like if they were to actually foster agility.

The episode in a nutshell: Dave stresses the importance of feedback, implicit in all values and principles in the manifesto, Human is startled by the post-agile future and Mary-Jane reflects on times when she was “canceled” by agile evangelists.

Shownotes:

• Dave’s talk at GOTO Conference 2015: Agile is dead
• Dave’s blog: The Coding Gnome 
• Dave’s book: The Pragmatic Programmer

Transcript

SPEAKER_01 0:00

Agile culture, agile leadership. I read a book a couple, I saw a book a couple days ago. It says leadership in a post agile future. And I'm like, what the fuck?

SPEAKER_00 0:20

That's how you know you succeeded when someone comes along with a post.

SPEAKER_03 0:41

Hello and welcome to Conference Therapy. As you can tell, uh today's um unusual episode, as it will be in English, and that's because we have a guest joining us from overseas. I myself am dining in from Frankfurt, as is my colleague Human. Hi Human.

SPEAKER_01 0:59

Hello.

SPEAKER_03 1:00

Hi. Um our guest today is Dave Thomas. Dave, you call yourself the coding gnome, which is also uh the name of your blog where you publish articles and videos and other posts on programming, and we'll of course be linking that in the show notes. Um but your work and your publishing has had an impact far beyond just programming and the coding scene, because Dave Thomas was one of the co-authors of the Manifesto for Agile Software Development, or as it's sometimes called, and I know you don't like that term, the Agile Manifesto. And this manifesto has had or has been an inspiration for so many industries. We hear it, we hear about it all the time, not just in software development, but also in product development, in organizational design, and I'm sure many, many other areas. For us, this is really an interesting topic because agile has been one of the biggest buzzwords surrounding everything organizations and how people want organizations to be, to behave, to react. So we're very, very excited to have you here today and to for you to give us your thoughts on agility and the agile movement and all the industries that uh surround it. Maybe you could start off by telling us how did this mysterious document, how did the manifesto for agile software development, how did this come to life?

SPEAKER_00 2:43

Well, good question. Before I start, let me just apologize for forcing you into English. But if you'd ever spoken to my German teacher at school, you would know that that was a very, very good idea. Um, that was probably my worst class in school. Um, which is a shame, actually, because I really wish I had uh the kind of fluency that you have in English. Anyway, anyway, so how did the Agile Manifesto come to be? It was kind of an accident, actually. The context is that we were at the end of the 1990s. Frankly, software was in a crisis. For years, we had been thinking that we were very, very close to having some kind of engineering or scientific approach to writing software. We had put in place some really quite complex, is the best, is the politest way of describing it, systems for managing software projects. None of them worked. We were constantly failing to deliver software that worked, and we were constantly failing to deliver software on time. The reality was that well over half of software projects never finished. It was it was a disaster. At the same time, there was a group of people in software who were kind of like seemingly ignoring this and actually delivering good software on time. And a lot of those people were just on small teams and practicing software development the way they thought it should be done. Towards the end of the 90s, my business partner and I, uh Andy Hunt, wrote a book called The Pragmatic Programmer. The idea of the Pragmatic Programmer was to try to ignore all of this advice that was going around and instead just go back to the basics of what works and what works for you in your particular situation. To our amazement, that book took on a life of its own. It became quite popular. As a result, we started getting invitations to lots of different conferences. At conferences, you tend to meet the same people at each conference. The people we were meeting all shared our kind of ideas of how software should be developed, or more importantly, how software should not be developed. So we thought to ourselves there must be some way of codifying this, of actually expressing what we meant. Someone, I think, I can't remember to be honest. I think it may have been Alistair Coburn, organized a get-together for 17 of us in Snowbird, Utah, which was a ski resort up in the mountains. We got there and sat down within maybe half a day, had worked out the things that were important to us and the things that weren't important. We wrote those down. Uh, we then elaborated a bit further on it, but really it was that this is important, this isn't important. Those things were the key of the meeting. Uh after the meeting, uh, we put together a very simple, like I think it was a single-page website where we just listed those things out and we invited people, if they agreed with it, to add their name to a list. To our amazement, uh, that list grew pretty much exponentially over the following year, to hundreds of thousands of people signing it. Thus was born both the concept of agile and the uh military-industrial complex that is agile.

SPEAKER_03 6:21

Let's call it the movement.

SPEAKER_00 6:24

Well, I don't know. Movement, you've got to be careful because movement implies it's it's the individuals gathering together and sort of like, you know, raising their pitchforks and storming the gates. But in this case, I think there's that, but there's also the other side, which is the hey, we can make money doing this.

SPEAKER_01 6:42

In the beginning, when you guys created this artifact, how long does it take uh did it take that it became this, I will call it phenomenon, especially in the business world, that if we look today, it seems that it is everywhere.

SPEAKER_00 7:01

I think that in the software world, it probably took about two or three years for it to become normal for people to know what you were talking about with agility. In the business world, I'm not too sure I'm qualified to say. I get the impression it was probably maybe 15 years for it to become um pretty widespread. I think what happened is that well, this there's it starts off, I think, inside the software development organizations. You know, as as that becomes more entrenched there, then the other divisions within companies are kind of like, what are you doing? How's that working? And it kind of spreads out from there. And then there are consultancies who attack from the other end who are offering kind of like agile in a box. They then sell that to the C levels. And so it comes down from that side as well.

SPEAKER_03 8:01

Yeah, I think one thing that, or a parallel development was that many more companies became more tech driven and uh more software focused, and therefore there was just more people in touch with these thoughts and trying to organize companies that enable people to do better software development, right? As as the pure aim basically of organization development that accompanied it.

SPEAKER_01 8:28

I think the first time I hear for you, it was this famous talk you did at the GOTO conference, GoTo conference, which was labeled Agile is Dead, which is from 2015, so five years ago. I think it has 1.4 million views. Also, one thing we should put in the uh show notes. I think at the beginning you had this interesting perspective that we started this thing that it had this, let's call it idea of we should accept a context, an environment we have, which is complex, things are changing, projects cannot be planned in a let's say waterfall or whatever, and therefore, or software projects cannot be uh developed in a such way, and therefore, we need to create a principle-based framework, a principle-based approach to say how as a team can we deliver products which are more fitting because we have to accept that environments are complex and dynamic and so on and so forth. In the same presentation, you did also a second thing, which is the problem with with agile is that agile, I mean, something can be agile, but we cannot sell an adjective, we only can sell nouns. So agile become this product. This talk is five years old. Did this perspective change in the last years? Or how do you see the current state of agile today?

SPEAKER_00 9:57

Yeah, let me just go back slightly on what you said there because I think for me, the essence of agility is that yes, things are changing incredibly rapidly. And what that means is that you have to move decision making down the organization. Every decision does not go back up to the top and then come back down to the point. It has to be made in front of you. And so, in order to make those decisions, you have to have some kind of uh filter to say, is this a good decision or a bad decision? And for me, um I call those filters values. These are the things that we corporately value. You have to make sure that a decision you're making fits within your value framework, whatever that might be. And uh the manifesto lays out one particular value framework, and that's the four statements at the beginning. And so, yeah, I think the the reason that agility uh enables rapid response and rapid change is because it gives everybody a unifying framework in which to make those decisions. Do would I change anything or do I see it differently five years on? Uh, the answer is yes, unfortunately, I do. Because the talk was intended to say big A, capital A agile, which is people who are selling you a uh off-the-shelf solution is uh not working. It's not the way we should do it. Anybody who claims success at doing that, it's simply because of the Hawthorne effect, right? The fact that you're going into a company and changing it and monitoring it, yeah, it's going to get better for a while. But the reality is all they're doing is they're putting another layer of bureaucracy on top of what you're already doing. That kind of agility is dead to me. At the same time, there is another layer of that, which is the individual and the small team. Individuals and small teams can be agile in any environment. It's easier if your you know surrounding environment is also obeying the same set of values. But to some extent, you can isolate yourself from that and still be agile locally. My hope in the talk was to rekindle the enthusiasm for that kind of personal agility, which is why I try to break it down to those three steps of, you know, where am I, where do I want to be? What's the simplest way of getting there? You know, repeat. So my hope would be uh at the end of that talk is that we would see people re-embracing the the core values of agility. Instead, what I see is a lot of divisiveness. Uh, people who are realizing that there is an opportunity here to exploit the fragility that's come about and jump in with their own solutions, their own methodologies, you know, their own ways of doing things. I don't know. I'm big I I'm seeing an unfortunate decline of personal agility as well, I think, in the last five years. I hope I'm wrong.

SPEAKER_03 13:33

Maybe just for some context, for those who haven't read the manifesto, the the values that you're talking about are individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. And if I understand you correctly, the aim is to follow these values, you should be able to evaluate. Um, I like that this is the same in German with wert und bewerten, uh, same with values and evaluate. You're you're supposed to be able to evaluate if you're doing well, right? Like it does it make sense what I'm doing right now, but always given a situation, right? It's not telling you what to do exactly, but it's giving you a frame that gives you orientation to be able to, yeah.

SPEAKER_00 14:30

I guess it's the difference between people of faith who have a certain set of values that they try and live by, and then the law, which is rules that you have to follow, right? Ideally, one of them will fit nicely within the other or in parallel with the other, but the values are the open-ended ones, right? The the values are the ones that should work in any circumstance, whereas the law has to be specific to every individual circumstance. And so the the values I'm talking about, yeah, are ways to help you make decisions. Now, there's another side to that, and that is you knew you always need to know, okay, but was that right or not? And so totally implicit, actually, no, it's explicit in all of this is the idea of feedback. You should never start something until you know how to say that you're done. And when you do think you're done, you then have to evaluate okay, how did that go? How was that process? And what do I need to do differently next time? So everything you do, you have to think about the feedback because otherwise you're just gonna go off into a black hole somewhere.

SPEAKER_01 15:46

You had in your presentation from 2015 one slide which I really liked. It says agility, what to do, find out where you are, take a small step towards your goal, adjust your understanding based on what you learned, repeat. And then agility, how to do it, when faced with two more alternatives that deliver uh roughly the same value, take the path that makes future changes easier. Reading the the values of the agile manifesto, reading those statements or principles. I would argue if we train people or if we bring people to understand that look, there is not a process step ABC, and this is your success, or this is how you create a great team, or this is how you grew, this is success in your product, but rather it needs that you as a human being, you need to use cognition to understand the surroundings and the people around you, which I think it's a really important message. Also, your presentation five years ago was such an important message, but nevertheless, what we observe today and also five years ago, I would argue I see two different streams when it comes to agile agility or how the industry is uh commoditizing it. One of those is a more structured systematic process perspective, where we have frameworks like SAFE, right? Skate Agile framework or other derivatives, which if you look at it, they're quite complicated. This is like the one stream. I see that today is a big business, right? I mean, even McKinsey is doing it, so that's a big business. The other stream is more is coming more from positive psychology, like agile culture, agile leadership. I read a book a couple, I saw a book a couple days ago. It says leadership in a post-agile future. And I'm like, what the fuck?

SPEAKER_02 17:46

What the coin the agile era.

SPEAKER_00 17:52

That's how you know you succeeded, right? When someone comes along with a post, you know, you're not a post.

SPEAKER_03 18:02

Well, I mean, if if we would look into management uh history books from the future, I'm sure that there would be the agile era and that we're right about in the agile era, definitely.

SPEAKER_00 18:12

Yeah, yeah. Oh dear, oh dear. We are we yeah, yeah. We'll be like one of these little thin strips of sediment somewhere in someone's history. So I think even talking about quote agile culture is misleading because at its core agility is about people, individuals, right? Not cultures, not companies, not methodologies, but people. Those three simple steps of you know, do something and see how it worked, go back and do it again. That only works if people feel that they can do that. People feel they can do that in under two circumstances. First of all, they need to have the tools and the support in order to make those small steps. And secondly, and way more importantly, they need not to be afraid of making mistakes. Because in those steps, the chances are very good you're gonna take a large number of them in the wrong direction. You know, you're gonna start off thinking, yes, I know this is what I want to do. But you'll take a step and you'll look around and say, Ah, you know what, that wasn't so good. Roll it back. Yeah. Or maybe you'll take a step and you realize that where you were wasn't a good place in you know to start with, and you have to roll two or three steps back. That is very rare to find in a business setting where people feel comfortable rolling back in the light of mistakes. Quite often they'll say, Oh, that's just a small thing. I don't need to worry about that. Yeah, it could be better, but you know, let's move on. So as a result, you're building on a more and more fragile foundation as you go forward. I would say that the only culture that I would call an agile culture is one that encourages mistakes and also provides a safety net.

SPEAKER_03 20:24

What comes to my mind immediately is um that there's also an entire consulting stream and coaching stream, et cetera, on failure culture for companies, right? So also this, I think, has been there's an industry for it now. I mean, what you're saying, having the security and knowing if there is a mistake, it can like we can deal with it, right? So this I can even be brave enough to make that step because if something happens, we will work with it, right? I won't be fired, uh, so I won't be too timid to never make mistakes. And I also know that this mistake that I'm gonna make is not gonna risk the company's uh existence as a whole. So that's okay. And obviously, this is something very desirable in almost any aspect of organizations as a whole. I think it makes sense that this is a big thing for many companies. What I find interesting is that all aspects of this have sort of um established a vocabulary, and that this vocabulary is the is deemed as this is the right way of thinking and of acting and of speaking. And that I I uh often get the feeling that the speaking about it with the right words is more important than actually checking did we actually put in place tools and support processes so that people can actually act like this and can actually make judgments for themselves? Because an important part of the um of being able to make mistakes, but also being able to. Judge a situation, right, to then make a next step is, as you said, the feedback loop, right? You need to get feedback again. And a lot of the times, also with mistakes, feedback is only what you get from a boss person, right? That tells you yes, good or no, bad. And in that setting, then putting all the vocabulary that comes um with agility or that has developed around or on top of the manifesto is sometimes very confusing to me.

SPEAKER_00 22:31

I think you're absolutely right about the the vocabulary issue. And it's it's worse than that, even. I think it has become it's people hiding behind words, is what's happening now. We have this vocabulary, you know, sprint, scrum, retrospective, all this kind of stuff. As long as you know these secret code words, then you can do pretty much whatever you like, right? I think there are elements of cancel culture about this too, which I hate. Okay, so in software, uh a big part of getting feedback is doing automated tests on your software, because that gives you some pretty basic low-level feedback on yes, you hadn't broken it by making a change. Yeah, that's part of uh probably a good team's toolbox, is this idea of testing. But it has got to the point now where it's a religion. It's no longer just like a tool. If you don't write unit tests and don't publish your software with unit tests, then you are a pariah. You are, you know, people will not deal with you because your software doesn't have unit tests. It's moved from being value to being dogma.

SPEAKER_01 23:46

There is a thing today, if we look at business and organizations. I don't know if you're familiar with Friedhof Bergmann. He's he was a philosopher and he created a word or a concept which is called new work, which is basically we need to rethink our job system and so on and so forth. But he also he also said what business and management is really good at is taking something, a word, for example, which people think it is something new, something modern, something different, but just making the old thing look nicer, it's shiny, right? He he said he he explicitly said uh old work in a mini skirt. That's the same bullshit as before. And I have the feeling that with the success of an agile approach and software development, that people saw, oh, look, if you have autonomous teams who take ownership, good products are created. Why not taking this and thinking about going beyond software development? But at the same time, what I would say, what I observed from our practice is that there is two things. A, people want to change stuff, but they don't really start to think about the fundamentals, right? Like, what is it that makes our organization slow, rigid, bureaucratic, whatever? But they're more looking for a tool, a process, a step-by-step approach, and then they hide themselves behind those approaches. Like, if we do sprints and do a retro and a retrospective, we have prioritized backlog and our roles are clear. This is how we're going to be successful. And if you then start to talk to them and you say, like, look, let's observe this. Does it make sense? No. Then you realize it's in cult, right? It's it's like an ideology. Deeply in their thinking. We had an example of Mary, we were in a setting where she said review instead of retrospective, and people will look like blasphemia, right? Like, how can you say this? Uh, it's it's a retro. Yeah, well, we should kick you out of the call as well.

SPEAKER_00 25:51

I mean, geez, that's that's ridiculous.

SPEAKER_01 25:53

Yeah, so it's and then again, going back to the principle and value, so like, look, it's thinking and acting and understanding and reflecting and so on and so forth. So, this is one thing uh I observe is that people are hiding themselves behind a process and method because maybe that's giving them security. If I do this, maybe my life is gonna be okay. The other thing which I observe is there is this trend of the classic boss, the classic manager not working so well anymore. And now people, management leadership now calling themselves agile coaches. I have really the feeling that what I'm observing right now is that we are running through organization, McKinsey is one of them, and saying we are going rid of middle management, and instead we are implementing agile coaches with basically doing the same, but they're now coaches and agile as well. And I'm like, you don't really touch the problem here. You're just doing the old, just a bit a little bit more shiny with a couple of nice words.

SPEAKER_00 26:55

I think you're absolutely right. I think one of the other things about having this kind of tick the box approach is that you can use it to justify your existing biases. So I quite uh often come along, I come across teams who say we don't write documentation anymore, so we're agile. And the other thing that's interesting, when you think about the word coach, there's there's kind of like two ways of looking at coach. A good coach is someone who uh works with the players on the team, uh, looks at the individual players and their strengths and their weaknesses, and tries to develop those uh the strengths and also fix up the weaknesses, work on how people work together and choose good pairings that will help things work. And then there's the coach who goes to the locker room and screams at the team, you're failing, you're not winning, get out there and win. And I suspect that when management in traditional organizations think about coaching, it's the second kind of coaching that they're thinking about. It it still comes down to the numbers, you know, the quarterly reports and all this kind of stuff.

SPEAKER_03 28:09

I I so I have a different um uh perception of this because I I feel that a lot of the uh coaching aspect is very much the expectations that um leadership now behave as the first uh coach type, um, basically being encouraging and doing uh like trying to make sure that you have an environment in which you can grow and you can um actually get where you could get. However, there's obviously structurally the problem that they will still then evaluate your performance and that underlying they are accountable for the outcome of the team. So it's a bit of a double bind where you go, where you get people who are like, I want to be really encouraging for you to figure everything out by yourself, but also please, when you figure it out, figure the thing out that I want you to figure out. Uh so it's a bit uh it's a bit messy in that.

SPEAKER_00 29:04

Although, I mean, one of the answers to that is simply to cut down this length of communications paths. Traditionally, management has been the interface between the worker and the customer. The chances of an individual developer or an individual person on the assembly line meeting an end user is pretty, pretty remote. And in that environment, it would be the manager judging your performance. But if instead your individual developers or whatever, you know, the people doing the work actually were interfacing directly with end users, the manager would no longer have to be the bad guy. The other thing I would say is that I have not seen what I was expecting to see as agility started to spread would be companies starting to split themselves up into smaller and smaller units, because it's a lot easier to be agile when you're 20 people than when you're 2000. If you can find a way of organizing a company as a series of you know cells or whatever, then that would be to me that would get rid of a lot of these problems, a lot of the need for things like safe.

SPEAKER_01 30:20

I I don't know you're familiar with Conway's Law. I think that's actually an interesting perspective. Uh looking at it, and I think I mean it applies to technology, but I would argue Explain, please, for those who don't know it. Ah, Conway's Law. I hope I can um quote it correctly. But Conway's Law basically says that system creating systems will reproduce system uh will reproduce the system they are built upon.

SPEAKER_00 30:47

Yeah, the structure the the structure of the system they produce will mirror the struction, the structure of the team that produces it. Yeah. So the idea is if you have a team where you have two sub-teams, one that specializes in A and one that specializes in B, then the resulting output is likely to have two components, A and B.

SPEAKER_01 31:09

And this is where I would look at if companies say that, oh, look, there is this idea of we can create software, we can create products, which for our current context, and I think this is actually really important to understand that I would argue that the context, the environment in which companies today compete, they're highly dynamic. And therefore, ideas or concepts like agile, they need to be understood and need to be transferred and thought about also in uh different disciplines. And this is where I would go in and say, look, if you desire your organization to be more adaptable in a complex and dynamic environment where you need feedback loops, you need to teams need to understand where they are, teams need to understand are they progressing to their goal. But we don't have the time to each individual team to review, monitor, and do all that stuff. But we need that the teams are autonomous, but they also need to be loosely coupled. Looking at theories like Conway's Law, I would argue that this is where we need to address this. Me personally, I would I would argue that starting with your leadership to create agile leaders and agile culture in a post-agile whatever, you have lost the game. You have to start, as you said, for example, sell organizational design and so on and so forth. Because I think that also if I look at the manifesto, and here you can correct me if I'm wrong, it's extremely dependent on individuals working together to create an output. And understanding that as system designers, organizational system designers, how can we facilitate this? How can we make this strategically work on scale, maybe even, but not like having crazy processes and so on and so forth? On the other side, that's not so easy sellable than the three days become an agile coach uh seminar, uh, which I would say is much easier consumable for uh managers and organizations.

SPEAKER_00 33:11

And that's isn't that a shame? You no longer need to be competent, you just have to have gone on a course. When I talk about like you called it a sell organization, I think there's actually a second path which gives you the same kind of option. If you think, and I'm going to talk about software now, but I think it's a more general possibility. In software, as it gets more and more complex, the idea of producing uh one big monolithic chunk of software that does something is no longer uh popular. So instead, what happens is you produce a skeleton, a framework, and then to some extent you open that up and you allow people to add things to it. Those things are added independently. So you provide interfaces that they can attach to, but they've developed them independently. But because your framework is sitting underneath it all, it unifies all of these things. A simple example of that is on your computer today, you can go to a web page, you can copy some text, you can go to your word processor and paste it in. Chances are it will paste with all of the formatting from the original web page, the colors and the fonts and everything else, right? Now, the people who wrote the word processor had absolutely nothing to do with the people that wrote the web browser, but the two of them work together. That is the underpinnings of what I would argue is one of the most successful endeavors that humanity has ever embarked on, and that's open source software. Open source software has clearly uh changed the world, and yet there's no one in charge. It's instead it's all interfaces, it's all in the programming sense, APIs, application program interfaces. But it's all things if you honor those protocols, then you can play in that world. Isn't that also a model by which we can build other things?

SPEAKER_01 35:16

If you would ask me, absolutely, maybe Mary has a different perspective.

SPEAKER_03 35:21

Uh well, I I don't I don't have a counter-argument as in you should not do it, but I do have a I doubt that uh comes to me from the sphere of management, in which who then, because you just said nobody owns it, right? Nobody controls it, nobody it's it's not planned by it's not planned centrally, therefore it's very hard to predict, very hard to control. And I think this is a a major core issue in organizations today and for the past many, many years, in which if I give away this control, if I open it up, what will happen? Will every everybody run amok and do whatever they want to? And then will there be a return on invest? I think this is like a big fear that this doesn't uh address.

SPEAKER_00 36:09

Well, I mean, the answer to the first part of that question is will people run away and do whatever they want? The answer is yes. Uh, will there be a return on investment? Who knows? But then again, who knows anyway? The biggest fallacy of management is that they have control. There is no control. It's just by taking incredibly uh conservative small steps, you can minimize the downside. But at the same time, you greatly minimize the upside. It's what it's an exponential curve. If all you're doing is playing down the bottom end of it, you're never going to have those breakout successes. If instead you can learn to let go, manage stochastically and not analytically, you can move yourself up that curve. And every now and then you'll have one of those little breakouts that goes past the elbow. Venture capitalists call that arithmetic loss geometric game.

SPEAKER_02 37:09

Yeah.

SPEAKER_00 37:09

You can afford to throw so much money away if one of them returns 20 times what you put into it.

SPEAKER_03 37:14

I think that's a very smart statement because with innovation or with any successful product, it's very hard to tell what will work and what will not work and what the customer will love and will buy, and so on, and so on. So it doesn't make sense to just invest broadly, and then one of it will probably end up being successful, rather than saying I will plan this one thing and I will push it in a way that I will get some money out of it.

SPEAKER_00 37:42

Yeah. And it's a lot easier to diversify if the cost of individual attempts is small.

SPEAKER_03 37:49

Agree. And this then goes back maybe also to the structural argument that we had earlier, right? With in a cell structure or with small teams, the um the impact you will have is much better observable. So you and the feedback that you get is much more direct. So therefore, it's easier for you to take a step that is small enough for it not to break the whole system, but rather to go, all of these teams can take steps in many directions because all of them see different things, right? And they can venture out and uh do stuff.

SPEAKER_00 38:18

And then the goal of management in those environments is to try to ensure synergy between all of those different groups, because that's what makes you a company. What makes you a company is that you have all of these weird things going on, but they all work together, and the sum is greater than the parts.

SPEAKER_01 38:40

Maybe I'm biased a little bit by the term synergy because it's such a management term.

SPEAKER_00 38:45

But sorry, I know, I know, I know, and I stopped, I was thinking what can I say instead of synergy?

SPEAKER_01 38:50

You know, I'm I'm I'm trying I'm trying to build up on this. And I'm gonna say maybe the job of management or leadership or whatever we want to call those people is to create a stable stable platform, you know, it's less about I decide what is good or I evaluate and say this and this, this should this should be it, but rather how can we create a platform where then people can freely decide, evaluate, exchange. I mean, what we what I'm explaining is basically market economies. If we look at our society, we say, oh, look, it's good, let the market decide because it's complex and the market is a mechanism which can deal good with complexity and so on and so forth. But if you look into the organizations, we have planned economies and we have management and leadership evaluating, deciding, and so on and so forth. And there's a lot of situations where I think to myself, why not making an internal market structure where the job of the leadership is making that this works?

SPEAKER_00 39:59

If you look at any government, if you were to secretly ask the people in charge, given that they believe that their way is better than their opponent's way, do they really believe in open and fair elections? No, I would much rather be a dictator because that way things would be done right. I think the same thing applies inside an organization. You're given power inside an organization. Well, what you do with that power, you certainly don't give it away to some you know invisible hand. You instead, you know, you you exert it because you believe your way is right. Although it's not, that's what got you to where you are now, and you're gonna keep with it.

SPEAKER_01 40:39

I mean, at one point we have to accept that this is impossible. Like, I mean, venture capitalists doing this, right? I mean, they know that it is impossible. It is structurally random, which of those investments will become the next hit. So, therefore, my answer to this is not I'm a super great genius, I'm looking on their financial reports and I'm gonna say this company is gonna be successful. No, I have some frame, some idea, and I have a system which then I'm gonna I know that with this I can work with randomness, for example, right? I mean, I I incorporate randomness, chaos, or whatever into my approach. And I think this is where if we look at leadership, uh sometimes I'm shocked that this is not clear because the word is complex. No one can do it.

SPEAKER_00 41:28

Yeah, I think uh the the ideal leadership for a group of people producing something would do two things. Firstly, as you said, they would provide a substrate on which everything sits, they would deal with all the stuff they have in common, you know, the infrastructure things, all of the thousand and one things the company has to do to survive. But I think they also, and this is going to be, I I'm gonna use another one of your management words, I'm sorry, but I think they have to provide a vision or a set of values that defines the company. See, I think in the same way that the Agile Manifesto says software is not a process, or software development is not a process, it's a set of values. I would argue that an organization is not its products, it's the values that lead to those products.

SPEAKER_03 42:18

What I think is really, really funny is that uh I think between the three of us, we agree that the classical management organization is not the best way to go about organizing a bunch of people to create productive togetherness. And I think that this understanding is something that is at least talked about everywhere, right? So with the digital revolution and all the all that came about with it was the like some sort of friction in which uh emerged the the thinking of, oh, something needs to be different, right? And this, I mean, this has happened many times uh in history. Something happens, organizations are like, oh no, something uh is changing, might be the market, might be employees uh doing something. And then there's a sort of insecurity about how to move on. I think what's so frustrating now is that the the vocab the vocabulary around agility has is basically something to hold on to, where it's like, oh, this is probably this is gonna fix it. And there's also some some sort of um, there's two sociologists, Maya and Rowan, they call this mimetic isomorphism. It's like, I don't know what to do, so I'm gonna look at all the other people. Oh, they're all doing agile, so I must do agile too. Don't really know what it means. I see some like methods and I see some uh words. So therefore I will I will take those and hope that it goes well. And then also, obviously, this has all the effect of oh, I'm I'm a more attractive employer, like very modern, very cool. So I can do all this thing, these things. And the same goes with values and visions. And purpose. I think those are also very overused words. And they come or in in when I look at LinkedIn, right? How are they used? They're very much used from the perspective of the employees to be how would you like to be with each other? Right. So like things like respecting each other, which should be a fundamental why we shouldn't need to put it anywhere. But the the sort of vision or why do we exist, like what do we exist for? And how do we evaluate if what I'm doing how do I as a as an individual in this company evaluate what if what I'm doing is serving our purpose and doing is actually useful or not, right? These sort of values, they need to come from a from a um leadership or platform moment, because what they can then provide, which the other, the nice ones that we put on posters where we all agree, like, yes, teamwork, they don't, they don't give consequence, right? But we the values that you're speaking about is what gives consequence to our actions, because how else would we get feedback, right? So if this is something that is that our company values, there needs to be some sort of feedback mechanism, as in if this value is not adhered to, then something should happen. Because otherwise, what how does it matter, right? Otherwise, it's good to do.

SPEAKER_00 45:33

I have to say that pneumatic isomorphism is a fantastic phrase. I mean, I assume it just means cargo cult.

SPEAKER_03 45:41

I don't know what that means.

SPEAKER_00 45:42

Oh, you don't know cargo cult. Oh, Wikipedia, cargo cult. It is one of the most useful concepts of people blindly following the form of something without understanding the reason for it.

SPEAKER_03 45:54

Yeah, yeah, it's that.

SPEAKER_00 45:56

Uh yeah, why is it management's job to give that feedback? For example, if I was doing mass market software, like a word processor or something like that, and if I was in charge of that company, I would make my developers spend a day and month on the support desk listening to incoming calls. So they would see for themselves what's frustrating people, what's where the bugs are, whatever else, what people want. Yeah, that's not the entire bit of feedback, but that's a really important one. And you know, I uh there's there's a whole bunch of ways in which you can cut down this the length of communication chains. And I cannot think of very many in which the word management should appear. If you look at uh you guys familiar with the Dreyfus model? Uh also because the idea of that um is that people when they're acquiring skills go through levels. And when they are initially acquiring a skill, when they are a beginner, a novice, they have no context in which to place anything. And so they are not capable of making a decision because they can't judge anything. Whereas if they are an expert, then it's all done through context. And in fact, decision making becomes tacit, it becomes subconscious. You have intuition because you're you've already seen the patterns so many times. I think that there is an argument to say that within an organization there is a group of people, there will be a group of people who need uh direction and who need structure. To throw all of that away would be dangerous because it would eliminate half of the workforce. I think the trick is to provide both kinds of environment at the same time. And that's that's where I'm not too sure I see how that can be done easily. One idea I'd like toyed with is what happens if a company viewed themselves as being like a miniature venture capitalist. You have your employees, and every employee comes in as an employee of this company. You encourage uh people who have bright ideas, possibly related to your existing product line, possibly not, but you encourage them to make proposals to you. And you you you spawn it off into, and ideally, you spawn it off into a kind of like incubator environment where you provide the infrastructure like payroll and buildings and this kind of stuff, but they you know, you never ever get involved in their decisions and just see what happened.

SPEAKER_03 48:49

And I mean, there are some very few companies who take this approach and they're wildly successful. Surprise. Yeah.

SPEAKER_01 48:58

Higher, for example, right? I mean, they do this with 40,000 people. Valve, I mean yeah, Valve with 400 people. We need really to do a podcast on Valve. I don't know if you're familiar with Valve, they're a software development company from video games near Seattle. 400 people, uh distributed organization. I think they're doing with 400 people 7 to 10 billion dollar revenue a year, quite successful. Yeah, I would say per capita the most successful company in the world.

SPEAKER_03 49:23

And they scrap projects all the time because they just didn't work out, and some of them did, and it's just initiatives that I so I wanted to uh know if the the team that came together and wrote uh the manifesto on agile software development, if they have somehow like, are you still in in touch and are you exchanging thoughts? And what's coming from this?

SPEAKER_01 49:51

Wasn't this this year 20 years anniversary of the manifesto?

SPEAKER_00 49:55

Yeah, I think it was. I think it was. I of the entire group of people, I am probably the least uh what's the word I'm looking for? Social, maybe? No, um, I I have not stayed in touch deliberately. I mean, I see these people a lot, uh, certainly before COVID um at conferences and things. And it was always fun. You'd bump into them and you'd be able to chat about, you know, the state of the world and whatever else, and basically just sound like old people everywhere sound. But I have not participated in any of the celebration organizations. You know, they had like a 10-year anniversary, and a lot of that is because a company formed called the Agile Alliance, which I fundamentally don't like. Well, that's not true. I dislike the idea behind the Agile Alliance, and so I don't go to any of their events and then they tend to organize all of these gets togethers. To be honest, most of that group of 17 people, they're all doing their own thing in their own way. There isn't much uh uh day-to-day in common between what we're doing, uh, and I think we also all realize that uh the events at Snowbird was just a one in a million serendipitous thing, it just happened. I think anybody who tried to reorganize a get together like that knows that it would just be disappointing. No, we don't really. I mean, it's it's people like Kent Beck, it's like a stroposcope. You know, I see him once a year, and it's always good fun. We tease each other, and it's always fun because we'll go to conferences and we try like during the meals, we try to like just move out and and just sit at a random tables. And every now and then we'll sit at a at the same random table and we'll totally shock the attendees by insulting each other for an entire lunchtime. That kind of thing is fun, but it's no, I I I don't stay in touch with them.

SPEAKER_01 52:02

Back then, when you when you were doing this, did you guys been aware of the impact that it could happen with the manifesto? No idea at all. Could you imagine that it becomes such I mean, two things such a big impact of uh organization and businesses general, and as well as such a big industry?

SPEAKER_00 52:27

I think if I'd realized it would become such a big industry, then I'd be worth a lot more money than I am now. No, I mean that's cynical. No, I don't think anybody did. Uh, I think some people had a better idea than others, uh, and some people did actually form businesses around the manifesto afterwards. But I think we all went away thinking that's pretty cool. I'm glad we did that, and it really helped me. I think everybody felt it helped them uh crystallize their thinking. I don't think anybody imagined it was going to get as big as it was. It was kind of one of those things where when we did get together, we would kind of look at each other like, what happened?

SPEAKER_01 53:11

Do you have a perspective? How did it become a thing? Like if you look at it and subjective subjectively evaluate the the past, can you can you see like what were drivers or things that today it is a thing? Um, I mean, if no one had an agenda with it uh 20 years ago, how how how did it become a thing?

SPEAKER_00 53:32

No, is the simple answer. I don't think I can look at a couple of small factors, but I don't think they are the major factors. One clear factor is that everybody in software at the time knew that we were doing it wrong. We just didn't know how it just felt that we it wasn't right. It was incredibly frustrating to constantly fail. So I think seeing anything arise that came not as a tool that was being sold to your company, but as a kind of grassroots uh movement, a set of ideas from actual working developers offered a bit of hope. That's one of the reasons it got big. I think it also got big because there was some buzz around Kent Beck and his extreme programming methodology. A lot of teams were looking to that, but the trouble with extreme programming is it was called extreme programming. For many companies, that was just like, no, that's too scary. It kind of offered a way of getting XP in the door without actually pushing too much. It also allowed teams to start adopting it without actually telling anybody they were adopting it. I've actually seen some quite interesting implementation models based on that. There was a company here in the States, software company, big software company, many thousand developers. They had lots of teams, and one of those teams finished one of their projects early. Their next project wasn't due to start for like six weeks or something. So their project leader wanted to experiment with these agile techniques. So he went to his boss and said, Do you have any projects that have been stalled that have problems that we could maybe uh take on? And he said, Oh, yeah, we have one project that was supposed to be six months, and that was two years ago, and it's still going. You know, you could have a look at that if you want. So he said, Okay, give us a meeting room and a month. They went into this room, closed the doors, and a month later, they delivered 80% of the software. It was the 80% that people wanted. And so the project was complete. And the management said, How did you do that? And they said, Oh, we're not gonna say right now because you know, let's give us another one and see if it see if we can do it again. So they gave them another one and they did exactly the same thing, at which point management said, Tell us. So they said, Well, we're doing this thing called agile. They explained how it worked, and the management went, Wow, we're gonna make all of our teams do that. And they said, That would fail. Instead, what they did was they, I think it was 12 people, they split into two teams of six people and brought in uh another 12 people to work alongside the two teams. So they split into two teams, 50-50, uh agile, not agile, and they did the same thing. And then after a couple of months, I think it was like a six months or something, they split again. Gradually, about half of these thousands of people were doing it using that agile way from the ground up. That is a really interesting model to think about. It's a little bit anarchic, I can see problems with it, but I think the the concept behind it is perfect.

SPEAKER_01 57:11

One important thing you also said in this uh talk five years ago, Agile is dead. Even though you say it is dead, it shouldn't be dead, right? I mean, the idea and the principles and the values behind the agile industry, so to say, that they are very important and maybe even more important today than ever before. What would you? I mean, you you've always been a programmer, right? I mean, you never went into consulting and do uh large-scale projects where you try to uh sell people coaching or so on and so forth. But if you would talk to leadership, CEO, CEOs, and so on and so forth, and they're like, look, we want to take this seriously. What would be your perspective if they like really want to go into the idea of you you guys created 20 years ago?

SPEAKER_00 58:04

I would say, first of all, that's fantastic. I would say, do you understand the consequences? How does that change your business model in terms of planning, in terms of profitability, in terms of overall structure, like the hierarchy type structure of the company? Fundamentally, I would say prove it. Prove it by demonstrating it and leading by doing it. Now, here's the thing I don't think that would work. I don't think it would work because the C level people would love this. The C level people uh know that this is correct, know that this is a good way of doing things in general. But the V-level people, the people below them, those are people who are entrenched in the existing structure. They have fought their way up the hierarchy and they have a vested interest in that hierarchy. And so I'd think it would be very hard if just the C level people and the workers down below were to try this without having total buy-in from the middle layer. When I see resistance, it's typically at that middle layer.

SPEAKER_01 59:26

Did you ever heard about Gary Hamill? He's a scholar in the US. Yeah, he wrote an article about such a transformation, and it was uh titled, and it was in the Harvard Business Review. First, get rid of all managers. I think one important thing he also says, and which I would also uh agree with, and you also said this, is doesn't mean that you put people outside in hostility, but rather create an environment where it is safe also to work to try, and so on so forth, uh, so that such people can really work great together. Maybe one thing I really have to say is a big thank you that you guys did this 20 years ago. I don't think that we as a company and also me as an individual, I was highly inspired, not by the management books, but by the classic manifesto. It helped me and it also motivated me in one way, which is don't make stuff processual and always think about the principles and the values instead of creating complicated big systems. Uh, I would argue there are many, many people out there in the world who are highly inspired and also change really things based on your work. So thank you very much for that. Uh, it really impacted at least my work. This is what I came for sure.

SPEAKER_00 1:00:54

That's very kind of you. It's very humbling to hear that. I mean, from my point of view, it's just common sense, you know.

SPEAKER_03 1:00:59

So well, in that case, thanks for spreading your common sense. Um also thanks a lot for the for the talk today. Looking, I took some notes on the side, and we made quite uh quite a detour also because we started with the the manifesto and how it came to be. You talked about the the need for values and for feedback and personal judgment, right? That it's about the individual people being able to act. And then from there, we sort of went to how the industry has uh taken it and commoditized it, um, making big bang from it by uh selling processes and vocabulary and all that stuff. And from there we went to company models and what would it mean if a company actually worked in a similar way that you think also software development works and we came to sell structures or thinking about companies as venture capital firms, going to smaller teams, enabling them to actually uh you know take those steps and and have control and get the feedback because it's easier in smaller teams. And from there, somehow we went back. We we we crossed how do people learn and does it make sense and uh what structures should stay in place and what not? What does management have to do with it? Where in management is this important? Um, how did the manifesto uh continued, or rather, how did you continue in the scope of it? And um I think uh yes, also from my side, uh very big, big thank you. Because I think regardless of if some people take it to a to an extreme or to a cultish, a religious thing, the the thoughts uh that you published uh 20 years ago, they were highly influential and I think gave a perspective on problems that didn't only exist in software uh development, but also in management and just giving that new perspective has done so much. So uh also from my side, a big thank you.

SPEAKER_00 1:03:05

I would say that the principles in the manifesto apply not just to business, but I think you can actually also use them in life in general.

SPEAKER_03 1:03:13

Yeah, um, so especially working software over documentation.

SPEAKER_00 1:03:20

Well, no, but no, but what it would be it's basically doing over talking about doing.

SPEAKER_03 1:03:27

Yeah, no, I agree. That's true.

SPEAKER_01 1:03:28

Yeah, one thing to those who listen through this, listen to the talk from 2015, Agile is dead. I think that talk alone was a great motivator of mine to under to don't fall into the trap of this bubble, pretentious bubble of agility people, where I think uh also Mary and I were sometimes lost, like uh maybe we don't know.

SPEAKER_03 1:03:59

But we want responsiveness, we do want other organizations. Why does it feel good?

SPEAKER_01 1:04:05

And I think your that specific talk you gave uh was I think also a great motivator for us to say, look, it's not about uh uh this cultist thing, like uh having all the world rights, but rather it is about a perspective of how we think, how do we want to act, and how do we want to be perceived and and also uh collaborate with others. And I think that talk is amazing.

SPEAKER_00 1:04:30

Well, it has been an absolute delight talking to the two of you. I very much appreciate you inviting me on, and then I apologize again for my non-existent trip.

SPEAKER_03 1:04:39

Super cool. Thank you so much. Thank you.