Latest / einfach gelöst / #9: Jim Coplien – "Agile is slower than Waterfall (but...)"
Transcript
- Stefan Roock (it-agile): Hello and welcome to the IT Agile podcast Einfach gelöst. That translates to solved in a simple way a more subtle ⁓ interpretation could be being relaxed. ⁓ I'm very happy ⁓ have Jim here in our podcast call him ⁓ for listeners who don't know you already, may you introduce yourself? Cope: let's see. So, ⁓ I've basically been a software guy in my career. I'm originally from the United States, currently live in Denmark, and ⁓ have a background in electrical engineering ⁓ a master's in computer science and a ⁓ in computer science and a doctorate in philosophy. I've been living in Europe for the past 20 years and ⁓ my most recent work has been in the Agile arena. A colleague of mine approached me when I was working at AT &T as I was really interested in the early work on object-oriented programming and said, you know, most of the problems are people problems. And so I started looking at process and organization and ⁓ Eventually did some of the work that in fact laid some of the foundations for Agile and I've been doing a lot of work in and around the Agile community ⁓ for many, many, many years. ⁓ Linda Rising, ⁓ who by the way you should also interview if you haven't, ⁓ she's very cool. says, know, cope is someone who was Agile before Agile was cool. ⁓ So we'll see how things go today. I don't know if I'm proud of that or ashamed of that. and so mainly I've been a consultant for the past 15 or 20 years. Before that I've done work in EDA. Was that an EDA startup? I've been a university professor. for a few years and in fact have had professorships all over the world in Australia, in the UK, in the United States. My main work was at Bell Laboratories for about 20 years. Stefan Roock (it-agile): mentioned ⁓ that you laid some of foundations of in a way. May you introduce us to this work? Cope: Well, I could be really nasty, and ask you, well, what do you mean by Agile? Right? And I've done a lot of thinking about that in preparation for this. And of course, this is in celebration of the Agile Manifesto. And I think even there, many people... Stefan Roock (it-agile): you Okay. Cope: The 17 guys who were there, every one of them brought a different vision. I was invited to that meeting, by the way, when I was in the hospital having surgery, so I couldn't go. Each one of them brought their own vision, which was a little bit different. And so to me, the... Stefan Roock (it-agile): Okay. Cope: The core idea, the really worthwhile idea has been that of self-organization. I'm not even really sure if that was in the consciousness of the early Agile people. Most of Agile has kind of unfolded in the area of tools because, well, we're nerds and you know. ⁓ The way technology transfer works in this community is if you don't have a tool to go with it, you can't transfer the technology. ⁓ And I'm very distant from that part of the agile milieu. feel it doesn't have much benefit and sometimes it's been harmful. Now, like I say, what really got me interested was ⁓ this friend of mine, Moody Ahmad, who came to me and he said, you know, they're all people problems. And I was in AT &T, and this is ISO 9000 Central, so you had to be ISO 9001 compliant in order to break the European trade barrier. And ⁓ development came to us and research and said, okay, show that we're ISO 9000 compliant. I said, okay, well, I'll do some ethnographic studies and study your actual process and compare it with your process description, which you need to be compliant to show you are certified. No correlation. But this was one of the highest, most highly certified organizations in the world. I thought, okay, what the heck is going on here? So, I mean, they were really faking it. They were really, you know, and not in the, not in the Parnas sense. I mean, Parnas wrote this famous paper, you know, How to Fake It. I mean, that How to Fake It was kind of semi-honest, where, okay, you go back and fix the documentation to match what you did. And here, people were just out and out lying. You know, they'd lie to the certifiers. I would do studies of organizations for the next 10 years. Everybody was doing that. So in fact, these notions of self-organization and of short feedback loops and things, long, long, long predate the Agile Manifesto. And I mean, I got in on, I studied these organizations in this project in research. and tried to understand, what does work? So if it's not compliance to a written process, which is what the ISO people said, okay, what is it that makes things work? And over the years, I mean, in 1993, I published a very early paper that essentially had the same thing that Takeuchi-san and Onaka-sensei found in their research, that what makes innovative projects successful is everybody doing everything all the time. So you don't have a waterfall sequence of requirements, design, implementation, and test. You do a little bit of this, you do a little bit of that. Everyone's doing a little bit of something differently, but all as one mind around one table. So that's kind of what my research found. ⁓ I did some, I made some tools. I reinvented social network theory. ⁓ Made these tools from the bottom up and I found out that a guy named Kramer had stolen my idea 34 years before I was born. And ⁓ made studies of what made organizations work and looked at the communications paths and the structure of the organizations ⁓ and came up with Stefan Roock (it-agile): No. You Cope: kind of taxonomy of what makes organizations work. ⁓ And then some folks picked that up and said, okay, this is really cool. They picked up a few other things and they put some marketing packaging around it and called it Scrum. So. Stefan Roock (it-agile): Mm-hmm. Cope: Part of my study, little bit of my work was at a company called Borland, and they had just done a conversion from DOS to Windows of their product called Quattro Pro. And it's probably the most productive project that's ever been studied on the face of the earth. ⁓ And of course, they're famous for being the source of the Daily Standup. Bob Warfield, who was running the group there, of had them meet every day and ⁓ do kind of what the Daily Standup ended up doing in Scrum. ⁓ I'm not sure if otherwise that's what we'd call an agile project. We can get into that later because the stuff that the Japanese were looking at and where this self-organization notion comes from is in areas with very, very high uncertainty. Whole new fields. Okay, we're gonna go to the moon for the first time. Well, okay, no one's done that before. But what's interesting, if you look at Agile and the great successes, like Quattro Pro, tremendously productive, the source of extreme programming, C3 at Chrysler. What was C3 doing? They were rebuilding the Chrysler payroll system. No new requirements, just changing the technology to small talk. There was no uncertainty of requirements. They had the requirements. They had an existing system that worked. The requirements were known. The same thing with Borland. Borland was just reproducing for Windows what they were doing with DOS. ⁓ yeah, they added a lot of new functionality, but I mean still, a lot of these so-called breakthroughs or celebrations of early Agile, in fact, were not in the center of what Agile claims it's all about, which is dealing with uncertainty and requirements. And I think a lot of this has to do with, ooh, they had cool tools or something like that. And there is something very fundamental going on there. ⁓ It's a part of Agile that I really didn't invest a lot of studying because it was so obvious. And that is the technology. mean, are you a programmer too? Are you a nerd too? All right. So how much have microprocessors improved in throughput in the past 25 years? Stefan Roock (it-agile): Yep. lot. Cope: For single threaded computation, not for parallelism. For parallelism, it's exponential. But just for single thread computation, single thread ALU CPU, it's about a factor of two in the past 25 years. As of Manifesto is 2001. From 1991 to 2001, what was the increase in speed of microprocessors? Stefan Roock (it-agile): Mm-hmm. To be honest, I have no idea. OK. Cope: one to two orders of magnitude. So this is when the pension came out. And so you see, you know, the whole mode of development radically changed because processors were so fast. And this is kind of the great paradox. Because they were so fast, It allowed individuals to interact with the machine instead of having to stand in line with a card reader, because you didn't need economies of scale anymore to do things with batch. And so it was actually a move towards more individualized development of working with workstations that were now 20 or 30 times as fast as the mainframe five or 10 years ago, that I think was one of the major factors in changing the way people worked. And I think that was one of the main factors behind Agile. So in fact, it was really about technology. And that's the part that people loved, was this technology part. Stefan Roock (it-agile): What about reacting to change? Cope: Did it work? Are we better in the past 10 years than we were back using Lisp in the 1950s? Lisp was pretty non-flexible. Those guys made some pretty flexible changes. And now you end up with C and Java, and you're trying to do maintenance, and you have to rip out the whole core architecture. The Lisp people just use reflection, and they may change very easily. So I mean, I could theorize. If you said, Azure really has made things better, I can maybe find an explanation. Has it? And this is one of the struggles with talks like this. We don't have good numbers. Now people might say, okay, well, we can deliver things two or three times as fast. Well, that's great. The computers were 20 to 30 times faster than they had been before. You better be able to do things two or three times as fast. Stefan Roock (it-agile): Mm-hmm. Cope: I do think it's not quite that simple. Of course, I do think that Agile lit a fire under people about the people side and that we started having teams that talk to each other rather than going through a spec or some other kind of command center, a manager or someone else orchestrating everything. And I do think that contributed to the speed of delivering the right thing. There's actually some research that's been done that shows that, ⁓ and I can't, I've been looking for this paper again, I found it. It was a PhD thesis published somewhere in South America. ⁓ Agile is actually slower than waterfall, but it delivers the right thing faster. Okay, and I really think that is because of the human issue. I don't think that's a technology issue. And so I think that... Stefan Roock (it-agile): Mm-hmm. and Cope: you know, the Agile Manifesto kind of gave people license to not gravitate around a single authority or a single document. And I do think that had some benefit, some really big benefit. Stefan Roock (it-agile): Mm Yeah, I agree. So, and you mentioned the Borland case. ⁓ What I read about it seemed to me very, very interesting. ⁓ And yes, it was in the end a rewrite of an existing system. I think that's an important point here. ⁓ But still they were much faster than you would expect by average, right? ⁓ Cope: ⁓ Oh yeah, tremendously productive, tremendously effective. And I'll sometimes quote lines of code and okay, lines of code probably doesn't mean anything, but log base 10 of lines of code probably does. These guys wrote 1.3 million lines of code in 31 months. So that's 2,000 lines of code per programmer. Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Cope: per week. And so, mean, lines of code don't mean anything. However, there's something going on there that those guys are able to turn around things that fast. As a researcher, however, I'd caution you that there are a lot of experimental variables, and a lot of them are technical, some of them are sociological. ⁓ Let me just sidestep here for a second and talk about Scrum. Everyone knows what Scrum is and so forth. So Scrum was invented by Schweber and Sutherland, right? Well, no. Stefan Roock (it-agile): Mm-hmm. Cope: The first time we see it appear is in this book called Wicked Problems, Righteous Solutions. And they talk about how you would do software using the ideas from this research that Takeuchi and Onaka had done in NuNu product development game. And they said, you find the best experts in every area that you can find. Now that is not what XP or Scrum or Agile is saying. They say, okay, the process will prevail. You just bring in ordinary people and the process will win. No, no, no, no, no, no, no. mean, what these guys said in this book was you bring together the best experts. Borland did that. They had one of the best people in the world on inference engines. They had one of the best people in the world on databases. Okay, so that was a major factor. The other thing is that Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Cope: This was Bet the Company. So this had a lot of energy behind it. And if you look at the projects that were eminently successful, they usually have one figurehead. So it's a Steve Jobs or it's a Bob Warfield. Now Bob is interesting because Bob is kind of a humble, soft-spoken kind of guy. However, he was representing Borland's need to do this or die. I mean, they had to do this or Microsoft was going to eat them alive. And so there was a lot of passion. And I think you shouldn't underestimate that passion. ⁓ Some Agile projects were personality cults, like the C3 project. And most extreme programming projects where Kent Beck has been involved, it's a personality cult around Kent Beck. When Kent leaves, everything falls apart. It's not just XP. The same thing was true of Scrum. This happened at a, what was it? What was a company that Jeff Sutherland, where he was CTO, and they were really doing great things until he left. So, yeah, I mean, If you want to credit Agile for how Borland did well, well, okay, tell me what Agile is and I'll tell you whether that made a difference or not. I think it's a rich combination of a lot of things that we did not invent in 2001. ⁓ Maybe we realized them. ⁓ But I don't think there's this magic thing that a manager, if a manager, Stefan Roock (it-agile): Mm-hmm. Cope: feels they have problems. I don't think that manager can call in Agile consultant who comes in and says, know, take a teaspoon of Agile every day and you will be fine. I really think you need to be thinking in terms of the entire system. And in fact, I think a lot of the most important things are outside the boundaries of the stuff that Agile consultants usually talk about, because they're usually talking about the technology. If there's a secret sauce, that's just one of these phrases that people like to use. I do think it's a self-organization. It's small teams. And I know it's kind of politically unacceptable to say this, but I think another part of the secret sauce is find the people who have the deepest experience. You really want to find expertise. It's not just the processor, some tools, or TDD, or the programming language, or object oriented programming. It's people who know their ass from a hole in the ground. Stefan Roock (it-agile): So you're saying that in the end it's highly dependent on individuals, right? On having the right people there. Cope: And this is where the Agile Manifesto got it right. Agile Manifesto doesn't talk about teams. It talks about individuals and interactions over processes and tools. See, individuals. And this is something that I think the community keeps missing, okay? They ask you to leave your identity at the door, okay? Stefan Roock (it-agile): Mm-hmm. Cope: Okay, we're going to do egoless programming. We're going to, you know... be very nice to each other and just blend into the team and have a team mind. And this gets into things like political correctness and that whole movement, which is a big sub-movement of the Agile movement, which has been widely misinterpreted. And people think, ⁓ we don't want conflict. No, progress depends on conflict and exploring alternatives. And I think there's a segment of the Agile milieu that says, no, we all got to be nice people and there's never any room for any of this noise. I really think that's unfortunate. Stefan Roock (it-agile): Mm-hmm. And so is this dependency on certain individuals from your point of view the reason that ⁓ Borland doesn't exist any longer? Although they were that fast. Cope: Well, mean, Borland was many, many things. And Quattro Pro was one of them. And it was kind of, you know, a collection of things. And Borland sold off Quattro Pro to raise money for something else. I mean, you don't sell off your dogs, okay? You sell off the highly successful ones. And I mean, Quattro Pro was highly successful and they sold it off. By the way, Borland still does exist. It's been renamed. So it was called, I don't know, something named after the wharf in San Francisco. And some of my friends are still there. So I mean, it's morphed and changed, but I mean, it still does exist. It's certainly a shadow of its former self. ⁓ Yeah, we could go more into that. ⁓ I think one of the more obvious regions is that, I mean, there's a saying in English, all politics are local. All agile is local. Now maybe there's a thing called enterprise agile and maybe we can talk about how companies can pivot and so forth. I'm a big fan of the Toyota production system. which of course came out of Toyota and more deeply came out of Japanese industry. Toyota just kind of publicized it and made a big deal out of it, but it's a much deeper part of Japanese culture, many aspects of it. And there's a lot of things they do that agile people would find distasteful, but on the other hand, it's what's made Toyota the number one car company in the world. ⁓ So they understand something at the corporate level. I think the software people have never understood Agile beyond a single team. Now, again, if you view Agile as something that the consultants got together in order to increase their business, oh, there's a lot of them trying to figure out how do we scale up Agile to the enterprise level. There's Scrum of Scale, there's... They're safe. There's all these other things where people are trying to cash in on the opportunity to use the word Agile at a larger scale. ⁓ And basically, none of them work. The only one that kind of works, the reason it works is because it really isn't anything, is less. And less is not a scaling framework. It's a descaling framework. Stefan Roock (it-agile): Mm-hmm. Cope: But it's just kind of, okay, look at what you've got and then here's some simple principles you can use to ⁓ get back to sanity. But I think it's kind of unfair to say, Borland doesn't exist anymore because the agile phenomenon was not at a corporate level, even though the CEO was central to what was going on in Quattro Pro. Philippe Kahn, I mean, was central to what they did. He was part of that team. Stefan Roock (it-agile): Mm-hmm. Cope: and he was founder and CEO. Stefan Roock (it-agile): And just one more thing about the Borland case. I find it so fascinating. Something I read in a book ⁓ written by Wolfram Müller. I don't know if you know him, the Tame Flow approach. He cited the Borland case and suggests that it... Cope: I know the name, Stefan Roock (it-agile): He said in the Borland project they always had a product manager and a project manager. And Jeff Sutherland made the product owner from the product manager and the scrum master from the project manager. Cope: I don't think he made the Scrum Master from the project manager. The Scrum Master was a role that kind of emerged. ⁓ Now what's interesting, and I told you, I studied organizations for 10 years. I've studied over 200 development organizations around the world, making social network models of them, interviewing them, spending time with them. And one of the things, mean, yeah, a lot of them had project managers. And ⁓ when I came here to Denmark, I was invited by the Prøsik Lys from project leaders to give a keynote at their annual meeting about what project managers do. So I went back and looked at my notes. ⁓ What do great project managers do? And great project managers don't do anything. They just are. Stefan Roock (it-agile): ⁓ huh. Cope: They're catalysts. And in that sense, the Scrum Master is like what maybe a great project manager does, but it's nothing like what the PMI teaches you that a project manager is. And no, mean, Jeff definitely did not get the Scrum Master from the project manager side, though a lot of people make that parallel. I do think there's probably some parallels between product owners and product managers. There are some very stark differences that a lot of people, including a lot of Scrum Trainers, do not understand. And they just say, okay, the product owner is just a product manager. No, no, no, no, no, no, no, they're not. Though there are similarities. And some parts of the skill set are very relevant that you can carry over from a product manager to a product owner. Stefan Roock (it-agile): What's the difference between product manager and product owner from your point of view? Cope: ⁓ it's not an easy discussion. The... Product managers too often manage requirements. So they'll go to the market and say, well, can we characterize what problems that the market has. And so they're managing problems or managing requirements, and they give those to the team. And then the team does design. A product owner does design. They own the product. Now, this is something most Scrum teams don't understand. And a lot of product Product owners are acting like product managers and when they come, they just kind of wave their hands and say, okay, well, you know what to do. We got to solve this problem. Just, you know, find something to do it. No, what Jeff Sutherland intended is that when the product owner faces a team, like at Sprint Planning, what she will give the team is what's called an enabling specification. Yeah, we use the term, word specification is specific. What do product owners give the team? Use cases, wire frames. The wire frame for the UX. data flow models. I mean, what you're doing is you're setting up the team for success. You're giving them all the information that they need. What the team is specializing at is low level design and finding suitable technologies to make it work. But in terms of the external appearance, Stefan Roock (it-agile): Mm-hmm. Cope: of the product to the end user, that's specified by the product owner. And I think most product managers will instead manage requirements and say, we need to solve these problems. The reason this becomes a real problem is that you don't have to go very deep to ask an end user or a customer, what do you want, and get an answer. and then you put the label requirement on it, the problem is it's almost always wrong and users don't have a clue what they really need because they haven't had time to invest in the research to understand what's going on. So a great product owner will spend, you know, months doing research into what the needs of an organization are and really, you know, eating, sleeping with the organization every day. Stefan Roock (it-agile): Mm-hmm. Cope: to come up with a deep understanding of the problem, then proposing a solution to the problem and designing a workflow and interface that will tentatively solve that problem and asking the team to deploy it. And then we'll see. OK, we'll get feedback and iterate on the feedback. But I mean, product owner is a huge, huge, huge job. And any significant product, you have a product owner team. So the product owner will have people who work for her to do competitive analysis, do Kano analysis, to work on specs, to do prototypes. ⁓ Great product owners build prototypes. ⁓ And at Sutherland's company, the product owner would build a prototype, and that's how you give the specs to the team. You'd give them a working prototype that was pixel for pixel. Stefan Roock (it-agile): Mm-hmm. Cope: faithful to what the end product would look like. And then the team had to fill in the back end to make it work. Deliver a new feature in one or two hours. yeah, product owner is a much more heavyweight role than I think product manager is. Stefan Roock (it-agile): Mm-hmm. Okay, cool. Thank you for that insight. ⁓ A few minutes ago you talked about the Toyota production system and said they do things that may seem disgraceful for agile people. Do I remember that right? Cope: Well, I think agile people will at least find puzzling. I mean, if you look at the management structure of Toyota, I I don't understand it. I have like the Bible, the book on the management structure of Toyota. And it's several interleaving hierarchies of management ⁓ with a lot of counterintuitive. Stefan Roock (it-agile): Mm-hmm. Cope: properties. You asked about the product owner? They have, you know, for each car, they have a product owner. called the SHUSA, which is sometimes translated Chief Engineer. And they're organized with the secretaries, not with the engineers. They're on the staff side of the house. Now they have tremendous power, but I mean, it's a really, really strange organizational structure. ⁓ Stefan Roock (it-agile): Hmm? Cope: First of all, the amount of planning. And I think that's the biggest difference is that Agile, and particularly extreme programming are, depending on what Agile means, right, are very much against planning. Extreme programming says, okay, just do the simplest thing that could possibly work. Scrum is different. Scrum says we have the product owner doing all this upfront analysis and giving a specification. Toyota does the same. Now Toyota has an interesting trick. And a very, very few software people have brought this up. How does Agile work? Let's try something, send it out, we get feedback. OK, we take one more step forward. We're always making a step forward and correcting the mistakes of what we just delivered. I've never seen anyone throw this solution away and try it again. Stefan Roock (it-agile): Mm-hmm. Cope: What Toyota does is effectively throws them away, except they do it little more efficiently. What they'll do is they'll try two or three things in parallel. And they'll go through several iterations of this. And in fact, they have a very structured approach to how many control variables they have, how many things they vary, and how deep they go. So they vary breadth and depth. They... They decrease breadth as they go forward, but they increase depth to evaluate alternatives. They evaluate a set of alternatives. This is called set-based design. And it's a big part of their upfront analysis before, you know, before they start building the assembly line, before they get to actually building the car. There's some other tricks that they do. Stefan Roock (it-agile): Mm-hmm. Cope: ⁓ that enable them to build a car, design a car at about one third of the time that Detroit does so they can turn around to the market very, very fast. Detroit will master plan a mold for like a fender for a car. And then they put the parts of the car together and they don't fit by half a millimeter. Well then you have to build a new mold. Well a new mold is six months and a million dollars. What Toyota does is they build the mold and it doesn't fit. They go in and they shave a little bit off the mold. So every mold is designed to make pieces that are just a little bit too large. And then they'll incrementally go in and shave off parts of the mold until they have a perfect fit. So you don't have to go through this other design turn. Stefan Roock (it-agile): Mm-hmm. Okay. Mm-hmm. Cope: Now Agile people will do that in implementation. Toyota is doing that in analysis. There's this other thing called lean that most people think is a Toyota production system, but in fact is different. And a lot of lean is bad. Because a lot of lean was just some kind of nefarious consulting that the Japanese did to the American Toyota or the American auto industry in the 1980s during the oil crisis and filled their heads full of junk. But... Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Cope: There's some interesting studies that came out of the Lean Institute in Berkeley. And there's this wonderful paper called Negative Iteration, where one of the things he says is, know, rework and development is waste. And we know that, you know. Rework and analysis adds value. And I think the Agile people don't distinguish. Every once in a while, they'll use the word prototype. But I don't see prototyping being frequently or aggressively enough used by the agile people. It's always the product is the prototype. We're going to use the market as our test base. And I think that's unfair to the market. It's inefficient. By the way, the fact that you're always going forward, you never go back, it means you end up in a local optimum. Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Cope: So recently I've been campaigning very aggressively for set-based design to avoid this problem of agile teams of getting into local optimal by always going forward incrementally. Incremental iterative design is, in the end, gets you in the wrong place. Set-based design, at least of other ways to alternatives, it raises your chances of ending up with the right thing. Stefan Roock (it-agile): Mm-hmm. Cool. I like that. So now we covered the beginning before the agile manifesto, some of the agile manifesto, what is agile or not, safe organizations, ball and the technology dependency. I think that's a very interesting perspective. I've never thought about that in that way. And we talked about scrum and product owners and product managers and prototypes. And what do you think about the future? What will come? What's the next step? Cope: Well, I'm from Denmark and we had a physicist here named Niels Bohr and he was into ⁓ subatomic particle physics and you know there's something in subatomic particle physics called CPT symmetry that means that charge is symmetric and parity is symmetric. Time is also symmetric. The fact that time runs forward is an illusion. So one of things that Bohr said is be careful about predicting things. Stefan Roock (it-agile): Mm-hmm. Hmm. Cope: particularly if they involve the future. I mean, I'm a little bit pessimistic. I mean, I've been around, I wrote my first code back in about 1969. So I mean, I've seen a lot of changes. And now I started seeing a change about five years ago, which is people in Japan stopped being programmers and they started being integrators. And so, you know, what would take me... Stefan Roock (it-agile): Mm-hmm. Cope: you know, maybe 2,000 lines of code would take these guys 200 megabytes of code, because they integrate these frameworks together, each one of us contributes a little bit. And now I think we've come to the next generation of that, which is generating the code from AI. So programming, as you and I knew it when we grew it up, has ceased to exist. Stefan Roock (it-agile): Mm-hmm. Cope: Now, there's still going to be some programmers. I mean, you still need compilers, operating systems, people who are not going to, I doubt you're going to generate a compiler from AI, or at least design a good language from AI. ⁓ So there's always going to be room for a few programmers. But I mean, today, if you count the number of people who do programming, you know, ⁓ Stefan Roock (it-agile): Mm-hmm. Cope: from programming the schedule on their washing machine. I guess that's programming. The number of programmers we have, I I was gonna check and see how many there are in the world. It's tremendous. I think we probably only need 1 % of them. Now I've been saying this for 15 years. Stefan Roock (it-agile): Mm-hmm. Hmm? Cope: How many programmers do you think have lost their job in downsizing in the past two years? It's coming up on a million. So the industry is fondly correcting and fondly seeing that all these people who are running crap. are probably not needed. when Elon Musk fired, you know, 80 or 90 % of the programming staff at Twitter, the whole world was in shock and saying, ⁓ my gosh, they're dead. Well, guess what? They're still around. Now, I don't like Twitter, and maybe they've lost a few things, but I mean, they're surviving. So, I think in the future, Stefan Roock (it-agile): Hmm? Cope: It's hard to say which way things are going to go. If things are going to go the AI direction, and we continue to just throw money at that, because venture capitalists are throwing money at that hand over fist. I haven't seen the big killer payoff yet. So it's not clear to me that there's any value there. There's a lot of interest and maybe some possibility and maybe some narrow areas where it will have applicability. ⁓ I have a friend here in Denmark who's doing some pretty cool things with AI, but very, very narrow. I do think there's gonna be continued need for the 007 programmers, the ones who really know their stuff. Again, the folks who have the experience and the expertise, like in that paper that inspired Scrum. And that to me is what we call, is what I would call programming. And if Agile is about programming, Stefan Roock (it-agile): Mm-hmm. Cope: then I think the future of Agile should focus on that. My fear is right now, I mean, everyone's trying to sell Agile and AI. mean, Jeff Sutherland is out trying to, I mean, he's putting AI on everything. Oh, AI will build your product backlog. Oh, AI will run your team. And I mean, he just published something on LinkedIn that frankly, I did not understand about how AI was driving his Scrum team. Stefan Roock (it-agile): where the whole team is constructed from agents, right? Cope: Yeah, just what does this mean? If that kind of craziness continues, mean, then we're all dead. Thank God there's gonna be some people who have a conscience and are willing to put in the hard work and I think are gonna continue to keep the basic infrastructure alive. I don't know if we're gonna end up with more airline crashes. I don't know if we're going end up with more mis-fied nuclear missiles. I do think the software, because of this mass hysteria and mass ignorance, is going to continue to add cost with very little benefit. And I don't think people understand that. You have an iPhone? Stefan Roock (it-agile): No, Android. Cope: I have an Android phone, okay, they're a little better. ⁓ What percentage of the features do you use on your phone? Stefan Roock (it-agile): Don't know. Cope: What percentage of the software on that phone ever executes? But you're paying for all of it. And that's the story of our industry. We have all this software. We're using 10 or 20 % of it. And yet we're generating all this crap that's total waste. Taiichi Ono of the Toyota production system said, Overproduction is the number one cause of muda. It's the number one cause of waste. And that's where I see the future of software going right now. I don't know if the economy can sustain that. If the economy says booga booga and we get some good feedback, then it's going to go back to these expert craftspeople. And that's of course what I'd prefer to see. I'm so afraid that the software economy is a false economy. based on hope and hype, that we're gonna see an increase in all of this waste that started 10 or 20 years ago. And it's now just being accelerated to hell by artificial intelligence. So I'm not optimistic. Stefan Roock (it-agile): Seems valid. with the smartphone I just got a new one since the old broke and I'm very happy since the by accident I activated a feature on the older phone and I wasn't able to deactivate it again since all these settings and features were so complicated. that I have a tech background, I was not able to figure out what to do. And I had to live with the feature. ⁓ Cope: Yep, on our ⁓ new Toyota big control panel and you can connect the audio to anyone of several inputs, you know. And once you've connected the audio, I don't know how to disconnect it. So basically when you turn on the car, you will get radio. You do not have a choice. I have not figured out how to turn off the damn radio. Stefan Roock (it-agile): Mm-hmm. There's the thing, definitely. Okay, then, is there something cool, new stuff you're working on currently? Cope: No, I'm basically semi-retired. I'm out here in the hinterlands of Denmark in the middle of the sand dunes. ⁓ have our three horses, soon to be four horses, and that's life right now. I had thought of convening some kind of workshop where I bring together people of respect, know, the great minds, and saying, all right, what's next? Agile is dead. what's next or what should we be focusing on? Instead of lining our pocketbooks with certification and money, of looking at the problems of the world, ⁓ mean, maybe global warming is the problem to solve. How can we as software people solve that? ⁓ Maybe... maybe something else that contributes to world harmony. I mean, we still have all this discord and economic inequity that's behind most of the wars that we have. How can we contribute to that? ⁓ So I've been thinking about something along those lines rather than, still do some things with DCI, which is this architecture for object oriented programming I did together with Treyvon Ransko. But that's kind of in its, going into maintenance mode. I really, I want to be able to want to contribute to something that really is going to have value. And. Stefan Roock (it-agile): Mm-hmm. Cope: I've been thinking along those lines, but I kind of need a meme. I need a seed. I need somewhere to start. So if anyone's listening to this and has an idea of a meme or a seed or something that's going to bring people powerfully together behind some cause, know, send me an email, let me know. Stefan Roock (it-agile): Okay, cool. Hopefully people will do that. and then thank you very much for your time and all the insights. Cope: And thank you so much, Stefan, for inviting me. These are always fun.