Can I get faces? I've got to go to the cloud. It's recording No. Yeah, yeah, it records but I like to try to get the faces in. But you can only do that when you record to your own machine. And this account doesn't allow me to record to my own machine. I don't know why I'll have to I'll have to check a setting. Maybe I said something. But we're not starting yet. We always start a couple of minutes early and let people just chatter ask questions if you have. So anybody who's here can ask if you don't know if you came prepared with anything or not?
Not so far, not so far. Well, I'm going to say something then, and maybe something you all can pay attention to. And watch a little bit as you as we do this, the next hour is I've been really interested getting into how a lack of systems thinking causes fear in the workplace. And I do believe it does. Or maybe I should say it a different way, I should say, the lack of that systems thinking could help us reduce fear in the workplace. And most places, most approaches we have don't talk about systems thinking in a usable way. Scrum doesn't mention it safe mentions it, but doesn't follow it. And I want to be clear, I'm learning to be clear about what I mean by fear. I don't mean the fear that we have of going outside of our comfort zone, although I believe understanding can alleviate that to a large extent. I mean, by the fear of there's a lot of blame in companies and systems thinking tells us there isn't. The system is causing most of the problem and we shouldn't blame the people now I bring this up on this talk. Because as we'll discover when we get into it with the penta, I think the penta has a lot to do with how we approach problems and therefore the environment of that we're in. So there's a relationship here. And I don't think Tom and I've ever actually discussed that relationship. So maybe you all as you listen and watch and I probably will too since I have a vested interest in this by looking at how could the penta This is not what it was designed for, at least not in my mind. Tom's often deeper thinker and further looking than me. But I had not thought about this as a way to alleviate fear. But I'm actually now wondering if there is a connection there. In fact, I'm not wondering I'm sure there is I just don't think I've seen it at all the way. So when I would just give it one more minute that will start. People are coming in. Oh, thanks, Brenda, I think you're new. I haven't seen you before. I still don't see you. But I haven't seen your name before, I don't think and you're fine not to put video on although we always like it. I always like to see people's reactions. Although I learned as a trainer, although maybe this isn't true for zoom is a little coaching tip for trainers. And then after I give this tip we'll get started. When I first started training, I wasn't a 97. I might have done a training before then every now and then. But that's when I started really doing it as kind of a career. I was anyway pretty nervous at the beginning like oh my god, how am I doing? Are they getting this and all that. And I noticed that I would find a friendly face in the audience and look at them and nod. And they would always look at me and I probably saying what the heck is this guy doing? Why is he staring at me not nodding because I'm so brilliant. I noticed I was doing that. So sometimes body language is not quite as effective as you might think. Okay, so let's get started. This is being recorded. I want to the way we do this as we Tamera and I talk about 10 minutes each. And then we have open for q&a. And while we're talking you're free to interrupt this is a very informal is not like a normal presentation. Tom Gibbs here Tom, why don't you introduce yourself for a minute or two just because people may not know you although they should but a lot of people don't.
Okay, born in California 1940. Started at 17 years old with IBM service bureau in Oslo, Norway, and sort of been in the IT business ever since written a lot of books which you can easily find by Googling principles of software engineering management 19 Ada is cited by half of the Agile Manifesto signers as their inspiration. So I I can then build myself as grandfather of agile and take all the blame for how bad they badly they practice it. I'm currently 83 years old and Am I I'm at my summer cabin on the Oslo fjord, that's the Oslo fjord. We just had a submarine hopefully not a Russian one going past here. And we're on summer vacation for about six months here being retired people, we just had a spell of good weather. And what I'm, I'm the inventor of a planning language called PP language, which you'll find in all my books and writings, but most recently in competitive engineering from 2005, free digital copy, paid paper copy, if you want one. And this is a language, which helps you think about systems, and especially systems with multiple qualities and costs. And that's about enough. Because you find a rescan the internet somewhere,
I was pulling up since I'm sharing the screen, if you go to success engineering dot works, and go to Resources, and then books. And then see other books. I have some of Tom's books up there, we add a couple every week as we do this, or every time we do this. And in fact, the penta model, which we'll be talking about, you can get a copy of here. You can also see the recordings we do, again, go to the go to the success engineering site. And take resources and there are playlists on YouTube. And here's Tom Gildan, Al Shalloway. They don't always show up in this order, but it'll be up here somewhere. And every time we do a session, we put it up here, there's the third one of the series. Okay, so a little bit about me, I'm the CEO and owner of success engineering, I've been creating a new method of doing Agile, I suppose it's really not really new. It's a consolidation of what I've been doing for the last two decades or more, it's based on flow lean Theory of Constraints, it has the really weird characteristic that I believe you need to find out what you're up to, and then what your problem is, and then offer a solution and coming up with a predetermined framework. You know, it's a very novel idea. Sorry for the sarcasm. I'm a little bit in the middle of this right now. But it's actually pretty exciting. And Tom has been a mentor of mine, and one of my best friends for the last, I guess three years now we've known each other at least a little over because I knew when I was at the PMI. And that's been two and a half years ago, you should definitely learn more about what Tom has to offer. I mean, he's kind of modest, maybe not so much, but he's not arrogant. And he's incredibly brilliant. And he's one of my best Lerner people to learn from Besides being a great friend. And as I joke sometimes giving me fatherly and brotherly advice. That's good, but not necessarily wanted at the moment. So we decided we do these series because it'd be a fun thing to do. So what I want to do, here's a copy of the printer, you can download this, where I showed you on success engineering, I wanted to talk for a few minutes about how the penta idea came into existence, what was motivating me to first start talking to Tom about it, then how Tom and I kind of created the idea. And I'm gonna let Tom actually describe it because he's written this book is like 95%. His is really good. I mean, I've read it of course, and I helped him a little bit but the conciseness and effects of it is I would really say his, but here was the here was the thing that got me going about this. So I've been in Lean since the 80s. Okay, although I didn't really call it lean back then we just called it the Toyota Production System. I had a brilliant mentor business coach that taught us lean and Deming back in the 80s. We just studied Toyota, we didn't hadn't read the I don't know if the machine came that James roll had come out. But he had studied Toyota's methods, and we were learning a lot about how Toyota learn and what they did. And we mostly studied Deming to be candid, more about to Deming to twice as much Deming as there was Toyota, but it was still kind of all the same basis. And one of the things I had learned while I was a, I was a developer from like, 1970, to about 2000. I don't know three is when I kind of stopped. I did teach design patterns for a long time written several technical books. No more in the process and workflows. But one of the things I had learned was that the iron triangle was just wrong. It's, it's always been wrong, and inverting it. Now the iron triangle is you know, you take scope, time, and cost and the they're fixed. And you can maybe do two of the three and people say if you rush the three, then quality is gonna go down and that you can't pick all three because that'll be a disaster to quality. And sometimes you've seen scope, time and cost with quality in the middle. And it's just the wrong model. It's a horrible model. It was This proved at least 55 6070 years ago, I'm not I'm not exaggerating, lean disproved it. This was the whole Toyota production system model. The whole model of Toyota was how do you improve quality, and in the process of improving quality, and in the process of improving that, therefore, improving quality meant you had to improve your workflows. And in the process of improving quality and your workflow, your product got better, your costs went down, and the time to build them went down. This has been a living example of why the iron triangles wrong probably since before the Iron Triangle even existed, I don't know where it came out. But if it didn't come out, if it came out after the 60s, there was always a dis disproof of it. Okay, so I've always thought what we needed to do was look at the relationship between scope, time, and cost, and how you can use quality itself, not as an afterthought, adding costs. But as a design process from the front, which is what Deming talked about. He's the one who first said, you can't test quality. And he's the one he said, if you have different components of things, you have to have them work together. So the quality was a natural result. He said that when you do that cost go down. I remember an example of this, I read, oh, his back again, in the 80s. When I was first studying him, I think it was Mary Walton or something had a great book on dumping that I that we use. And she talked about how Levi Strauss you know, the maker of jeans that they were trying to pick up some of the lean practices, and one of the lean practices is work with your vendors, where your suppliers. And when they studied the workflow, they saw that the last step what do you think the last step of the denim suppliers to Levi Strauss was? It was inspecting their denim? What do you think the first step of the Levi Strauss's was when they received the denim, there was inspecting the denim. Now that's waste. You're doing the same thing, twice different companies, and maybe not up to either one of their standards. So it's things like that attending to the workflow. This, by the way, doesn't take courage on this courage thing. As I mentioned, courage and fear and stuff, doesn't take courage to do that. It just eliminates waste, like this kind of good, because now you don't have to worry about it so much. So anyway, that was the impetus, I suppose then, of course, I'm thinking, I'm thinking simply, let's just get let's eliminate waste by removing delays in the workflow that's lean in and flow. Also, theory of constraints for that matter. And things will get better. And then we got into the conversation. And I, as I recall, it took us It didn't take us that long, but it took us at least I think about an hour to get to that, well, there's a lot more factors than they are and you might guess what they are because there's a pentagram up in front of you when we call this thing, but then they've got labels on it. So that's basically it. So that was what got me into this. And this is really a very brilliant thing. Because it's not just it's not a model that constrains how you think, except it keeps you focused on what you should be thinking about. So this is a kind of, I won't say how to design that's one of the things in there. But it's a way to guide your thought process between these five things. Okay, so I'm gonna stop with that. And I'm going to turn it over to Tom and people can inject and ask questions when they have them.
Okay, before I say anything, anybody have a question or remark? Good time to do it. Okay, now, let's take a look at the Pinta. Notice the little red part of it called design, which, okay, that doesn't occur in the iron triangle. And in fact, many disciplines, for example, Scrum doesn't have any design concept at all. And if you don't have a design concept, there are certain things you can't think like the engineering design to cost becomes impossible, because you have no design. Okay. So it's amazing how much of our IT methods territory doesn't actually have design. I was just looking at some stuff and talking with a professor at an Ivy League university, who's doing stuff with drones and safety. And I couldn't really Find design. Okay, wasn't there. And, and she was based on Scrum, the price she recognized it had problems and had a safety scrum variation. But the idea of design to get the safety was there. And I've had my words with the professor, by email today, we'll see what happens. But so even at the top academic level of people doing these things, they buy into core ideas like Iron Triangle, like Scrum, and have problems with them. And they can't figure out why. And so you know, the, the key, the idea that design as a conscious process has to be there. And I've already said the word designed to cost which if you look it up to well known engineering idea, we can get almost any cost we want, if we design it to be cheap. Wow, that doesn't that beat things like planning poker, and estimation and all those other things? I mean, you know, ask, ask your managers what the budget is, and then designed to get it. Okay, what's what's, there's nothing new about it, but it's new for people in it. It is not new for good engineers. Take another one. There's a thing here in the upper right hand corner called values. Now, values is short for stakeholder values. Now, if you think about it, every project we do, every effort we're doing is driven by our stakeholders, and what drives them getting their values, this is like an unassailable truth. Stakeholders with their values are driving us. And if we don't know who our stakeholders are, and we don't know what their values are, we cannot deliver them. And if we do not deliver them, we will be failed in the eyes of those stakeholders, some of whom are paying customers who won't pay. Put it in simple terms. Okay. So again, what I, what I found in the work at the Ivy League University on safety of groans, was that they had values, safety values, but they were all binary, like we're going to have good safety wouldn't be an exaggeration of what they wrote. And the idea that safety was a variable. And there was more or less safety did not occur in any of the documentation in the papers on their website, from the professor. Okay, now, I mentioned this. And they went straight back to a form of user stories. You know, I want good security for my drone, because I'm a drone flyer. Okay, now, that's ridiculous. But it does pervade a lot of our culture. This idea that qualities and values are a variable, I want this quality of that quality, built into the user story idea. That's what they were, they were using that level of requirements, even though it said in the University Institute prospectus that we do Requirements Engineering. Now, the moment you don't quantify you are nowhere near engineering. That's called poetry.
Yeah, maybe? Yeah. Well, maybe not good poetry.
Okay, now I've I've observed something and you can observe it yourself. This the thing, the thing, all our projects are trying to do is deliver values. Notice plural, not a value, not profitability. But values. What are they? They are this stakeholder values? Ah, how many are there? almost infinite, if you think about it, but we can't go there because Infinites too much work. So we often do practical things like say, what are the top 10 values, the top 10 Critical Values critical mean? If we don't satisfy them, we're dead meat. There's a good little prioritization idea. Top 10 belts, we know there are 100 more easily and there are infinite. But if we, if we don't even tackle the top 10 We're dead. So who cares about the other 100? Okay, so there's a prioritization notion here, which I call critical values. I also have a thing called critical designs, which are the most powerful ones that will deliver the critical value the word critical is a nice little prayer. Integration thing, you know, deal with critical first, and you might survive, fail to even understand the concept, you're dead meat, your project will fail. Okay, so the idea of multiple values, it's amazing how many people actually think that the world of business is totally dominated by one idea called profit, or maybe growth. And that's the end of that. And that's the value of a corporation. Okay, take a look at somebody like Bezos or musk, what are their values? I mean, pretty good profit, pretty good growth. But mus trying to save civilization. Just number one value. And subsidiary values are critical safety in the car is built in designed in, not by accident. Okay. So, you know, these businesses, they have multiple values as their primary tools and profit and growth, they have to be there somewhere or they wouldn't survive. And Musk has often been taught a hard lesson on that from his shareholders like me. But, but that's actually not the point of what they do and why they do it. Okay, I mean, once you have $800 billion what's the point? What Why does he just retire and have a martini on an island? The answer is, it's not he's not doing it for the money and he never has. Okay, what about free speech? I mean, that's what he thinks he's doing with x. Okay, you can argue about how he's doing it. But that's, that's why he did it. Okay, now, get off the bus, by the way, have a little book called Musk's methods, which I will give you a free copy of, it isn't in their album, make a note, we'll give you my collection of Musk's ideas, which I think are very powerful ideas, even just his initial five, you know, what his initial five ideas start with? They start with the idea of a requirement. And it's amazing how requirements are not in some of the methods, you know, or they're very so poorly implemented as to effectively not be there, like a highly ambiguous user story is as good as not being there. It's just total ambiguous bullshit. Okay. So, but Musk has a really interesting perspective on that, and, and by the way, this is a synonym for values, you know, the value of the stakeholder values, we state them as requirements, value requirements. Okay. I've got a book on it called Value requirements, l free copy to our friends. And the first thing he says is, you've got to quantify it. No discussion at all. The Amazing how things like user stories. Avoid quantification. Totally. Why? What do they think is difficult? Or they're ignorant? I'm not sure. But if you ask chat GPT to show you 50 ways of quantifying security, which I did recently, it will do it and it will do it well. I can provide a copy of that you can generate one yourself. If you then ask Chad GPT. If I asked you to help me define scales of measure and thus quantify security 500 different ways. Could you do it? Yes or no? Guess what chat? GPT is arrogant enough to answer. Try it. Okay. It's not difficult. At least chat dept doesn't think it's difficult. So if you do, well, we better hire chat GPT and not you. You're ignorant. Okay. Now, by the way, the values are the key to what the designers has to do. The designer has to design something that will deliver the values. You don't get values by hard work. You don't get values by eliminating bugs and testing as many coders seem to think that's the only when they say quality, they mean bug lessness they don't mean security, safety, usability or anything else. mazing the narrow minded this programmer culture that's been driving it and by the way, you know, straight into Scrum and the Agile Manifesto. Bless my friends, they're and all that they're all coders at heart. They're not engineers. They're not architects, and they don't know what design to value is. They didn't say that so designed to cost before. But if you can design to cost, plural, you can design to value you can design. And that's what engineers do. Nothing new. So they've always done. Okay, from Egyptian times and before, nothing new at all. Okay? Now notice there's a little thing here called resources. Notice it doesn't say costs, or it doesn't say time. It doesn't save money. It doesn't even say human resources. It just says resources. And it's plural. Because there are a lot. Now the problem with resources is, that's not why we're there. We're there to generate value. But unfortunately, that takes resources, time, people money, let's keep it simple storage space, who knows? Okay, now, and it takes a plurality of resources. And there's a problem with the resources, they are not infinite for anybody, ever. And they run out historically, too early. Okay, so what we're trying to do, we're trying to plug in the idea of that there are multiple resources, just as there are multiple values. And you have to keep track of them simultaneously, like 10 critical values with five critical resources simultaneously. And people don't know how to do that. They can keep their eye on reducing the bugs and reducing the cost of generating the code. You know, that's a one plus one dimensional problem. But the moment you say, keep track of 10, state of the art competitive values, nobody knows about my definition to the state of the art and beyond. And keep track of incredibly scarce, let's say, specialized manpower to do this job. You know, how many AI geniuses and security geniuses Can you recruit today? Difficult. Now, the values over resources is an interesting concept. And that is efficiency. And we're not trying to maximize values. It's amazing how many people say that maximize value, no, no, no, no. At costs, that is facing the efficiency Enough, enough to be the winner enough to compete enough to be the best left to sell your stuff, but maximizing it towards infinity, you have got to be kidding. The mere phrase, we're there to maximize value, you see it all over the place shows how ignorant the speaker of that is, they don't understand you cannot just maximize, you know, you have to have limitations that limit your resources. So that your efficiency is great. By the way, efficiency is another word for profitability. Or as politicians like Cameron, that value for money to the voters. Okay. So that's not in there. Now, I won't go into scope. But
it includes more than functional scope. It includes things like all the constraints, like you have to have protect privacy in Europe, even though you don't have to protect it in the US Google $800 million fine as a result. Okay. And by the way, I've written another book I want to throw at our friends. It's the guides, book owl. And I've written a new book all about constraints and going very, very deeply into constraints. And want to give you a free digital copy of that. Maybe we'll have that as a separate subject later, but we want to keep it while the getting's good. Okay. Yeah, the topic. Oh, there's one more we ought to put, let's be generous upfront, even before we've handled some topics in detail. So I've mentioned designed to cost. I've written a book called cost engineering. Let's, let's give it to them make it available to them out. And you know, it's a separate subject worthy of a whole book. But it is what it is the detailed engineering things that are going on around this entire model, tend to attempt to model a top level simplified explanation of things in these books. I'll stop there. Okay,
I want to throw one other thing in and then I see Karen has got a question you can answer. So this is another thing that people tend to ignore. I'm going to show you this great cartoon. So Edgar Schein made a comment. We do not think and talk about what we See, we see what we're able to think and talk about. And I added that to this cartoon by sketch play nations, which is a really fun, you could look at that Scottsbluff nations, I think it's dot org or.com rather. And I have permission to make edits on this with for this guy. He's really brilliant. And this is like the old joke where a policeman sees a guy looking for something under the lamppost. He's looking for his keys. He's obviously knee braided, he asked him, Are you sure you drop them here said no, I dropped them down in that alley. So well, why are you looking here, the lights better. One of the powers of the penta is even if you didn't know what those five things were the fact that it tells you to attend to them, and maybe discover how they relate to each other that alone, that alone would be useful. This idea that we have to be purposely incomplete basically says, Hey, let's put our blinders on and try to discover the world for ourselves when these ideas have been around, like so I'm not saying pentane has been around for 70 years. But the idea that we needed an improvement over the iron triangle has been around for seven years, at least. Yeah, Tom, that was all I have to say. And then we can go into q&a After your thing.
Okay, I can't resist bringing this up. What I've learned quite recently, and is that Chet GPT, which is what I'm using free version for oprofile. If you ask it, as I already remarked, if you ask it for who are my stakeholders, you know, give me 50 stakeholders for this car company, it will give you a brilliant list, if you ask them it simultaneously, and give me the top three values of each stakeholder it will do it and it will do it brilliantly. If you then say, take the top 10 values from all of the stakeholders and quantify them by you does the language it will do it. If you then say, give me the top 10 strategies or designs for reaching the 10 values. It will do it if you then say build me an impact estimation table that tells me how effective your suggested designs and strategies are for reaching my goals. It will do it if you then say, Okay, bring in capital cost and operating expense for all of your things and put them on the table. And then tell me what is the most cost effective design? It will do it. If you then say take the top strategy and decompose it into 10 sub strategies, each of which will give a result and rate them by effectiveness on a table. It will do it by the way. Did you notice that agile? That last decomposition gave me agile sprints to deliver things that give effect and deliver value in sprint cycles. So Chad GPT knows a hell of a lot more about value delivery in agile than most of the methods you have been, had been brought about from scrum to the Agile Manifesto. signers, they're nowhere near this. They don't even know how to ask the right questions. Who are the stakeholders? What are their values? quantify the values? What are the most effective strategies decompose? So I get small ones? What are the costs? Those are the right questions. And if I can, if I can just now taught you to ask the right questions of chat GPC or your favorite AI, you are superior to any of the Agile methods in town. This is the what I call agile engineering. By the way, I have a set of slides on agile engineering. Let's include them. Yeah,
I couldn't resist that. But all of these up, and then we could promote them a little bit before the next talk. Now, Karen had a question, which I think you partially answered. But you said you can't maximize values. How would you describe how to best describe how to think about value? And I think what he actually said though, was that you can't just say keep maximizing, you know, like the maximum amount but it is the direction. So how would you answer that how to best describe how to think about value? Or did he already answer that? He did talk about it to some level of Karen.
Yeah, but I'll give it for now. Number one. You know, people say oh, we want to maximize value you say no, that That's not what you want. So how do you describe? value and how you want to work with it? Think about it.
Let me couch the how I think you'd like the answer. If you're talking to somebody and they say they want to maximize value, how would you respond to that question? They need something specific to hold on to if they can't hold on, okay? When
I was when I was a young economy student, we learned a concept called the the idea of diminishing returns on investment. And that's the key idea. In other words, there is a point where you're sick, your safety or security or whatever value has gotten so high, that two things will happen. You're the winner, you're better than everybody else. And any increment will cost you a bundle and give you no profit. You've reached the In other words, what you want to do is go to, let's call it at least not beyond the point of diminishing returns on investment, and probably want to stop at the maximum profitability level, we call that the goal level in plain which, okay, so you need to set a goal, which will beat the competition and make you profitable. That simple. Okay, and that's spelled out in detail in playing which in, for example of the competitive engineering book, okay, but maximizing or just keep on going and making him more and more without any limits, is ridiculous. But top executives say that all the time, you know, we Boeing, we believe in maximizing safety of the aircraft.
You know, another way to say this is you want to look at the acceleration factor of value increase, and after a while, it starts slowing down. And then you might look, is there something else that has a faster rate of acceleration? Yes. The I think what Tom's really pointing to is something way more insidious than the positive of what he's saying is, there's so much stuff that's just repeated by rote, without any thought at all, in the Agile space, and, you know, people forget, to me the most important words of the Agile space, a pull up of the Agile Manifesto. Since we're outside of just developing software, is this. And ironically, if that's true, then how are we still using this as a guide? 23 years later, except for maybe those words? And nobody seems to think that's makes sense, or a lot of people don't? Anyway, other questions? Just raise your hand? Yeah.
So if you are Boeing, how do you explain to, you know, your stakeholders in general public, that we don't want to maximize safety? You know, what I mean, it's a little bit of an awkward you have you come convey that,
you want to put your money holders here. And the thing is, you just don't keep going, you want to look to see where can you get the biggest return? Where do you get the best return for the money? Just saying, I'm gonna get more of this doesn't seem to work. So how do I get the best return for what I'm doing? But it's not going for infinite is going for the best return of the things I have. You always have a lot of you always have a lot of options. Now with Boeing. I mean, there's a lot of things that went wrong with Boeing. And one of the things that went wrong with Boeing was they actually changed their value. System back in the late 90s. When basically, McDonnell Douglas acquired them Now technically, Boeing acquired McDonnell Douglas, but I was there at the time, and I have a lot of friends. And when Boeing started running into competition, with, you know, Airbus, they kind of panicked, or the business people decided we're going to maximize profit and deliveries, and they gave up the value that had built Boeing of safety. I remember back in the 90s, I hated flying on Airbus planes. And I love flying on Boeing planes. And no matter what happened in the air, I remember looking out the wing once and a turbulence and this wing and I'm not kidding, it is going up and down and up and down. And if anybody didn't know much about that plane, I'd have been scared out of my mind watching this wing go up and down and up and down. And I was not the least bit concerned. Because I remember the tests they had run on those planes. They have this test where they take the wings and they keep folding them up. They call this a break test or something like that. It's a structured test, and what you expect to happen is at some weigh in at about 45 degrees, the wings break. On the I think it was a triple seven, the wings didn't break, they literally got them up to the top, they were that strong. And they change the value from safety to profit. So with a company like Boeing, it may be difficult to do this McDonnell Douglas, which has a heritage of making planes that meet the FAA regulations, but don't make that don't have the heritage of following basic engineering practices called no redundant, I mean, not having any, you always ever done this. So you don't have no redundancy. And the the 737 has a whole bunch of things about it. First of all, they shortcut things, making a stable, made an unstable plane didn't tell anybody about it, that was the control system. But then they only put in one air, its angle of attack, they had two angle of attacks those those, and actually, the angle of attack sensor they knew was faulty. They knew it failed every now and then. So they made a critical system to save money. So they didn't have to recertify broke engineering policy by not having redundancy in it. And then when accidents happened, you know, well, then they did what they did, which I won't get into. But this wasn't the first time the the actual old Dreamliner, which is a plane that they built via contract was to save money without long term thinking. So this is this, you see this shift? I think I'll tell you one thing where I misjudged the company was Amazon. I remember years and years and years ago, when Amazon was first coming, I was looking at how they were from a profitability point of view. And I was looking at the company wrong, because Bezos, his value was to create a good customer experience. And that was what they drove the customer on, they were losing money when they could have been profitable. And I was like, Well, these guys are never going to be profitable, they're not going after profit. And the answer is Al, that's why they will be profitable, because they're not going after profit, because they're trying to create a new customer better customer experience. And then when they got to great customer experience they want well, we need vendors who have a great experience now. I'm not judging them where they are now, but their values back then, if you can't get their values to line up with something that makes sense, there is no hope Garin of getting them to improve as a long winded answer. But I think that's really what Tom's talking about is you got to look at the customer stakeholder by actually, I do want to say make two comments myself, and then go on and you should be thinking about questions. There was something Tom said that he said it right. But I want to underscore it about, you know, in my mind, and I believe in Tom's there's no such thing as non functional requirements. It's a requirement, like security, you don't add it in after the fact saying something's in NFR is one of the reasons you have so much bad. And if Rs. It's built in from the front with security. And he's not here, but I'm gonna give him a public endorsement. If any of you need security, a security expert, it's Andrew tonally. He's in my amplio community Amplo consultant educators program. So I've talked to him lots extensively. And he views security in a system perspective, than the way we view agile in a system perspective, you can't add security after the fact then you just like playing What's that whack a mole, then you just try to figure it out. You got to get in the machine. This is why design is so important, because you can design it into the system because it's part of the constraint of the system. Okay, give other questions. I forgot the other thing I was gonna say. I'll think about it while you guys are thinking about it.
says that with McDonnell Douglas, it isn't limited to aircraft companies that they acquired in the 80s. They acquired a lot of small successful companies in it. And because they wanted to diversify, and probably they wanted to be more profitable. And what they did in large part was they ran them into the ground and sold them off at fire sale prices. Yeah, yeah, this happens a lot with acquisitions when the values of the company buying a small company that's successful has different values, the values of the small company gets basically destroyed. I've seen that happen. Microsoft's done some acquisitions that way in the past with telephony, and stuff moguls.
You know, I'd like questions if it was there somebody else who was about to ask a question. Victor Yeah, please. I'm not sure. It's
a question per se, but an appreciation for the framing of the values part of the penta diagram. Thank you, Tom. Bill, it occurred to me that you're talking about you cannot maximize the value is a potentially infinite. And what occurred to me, after thinking about that for a few moments was that undervalues one of the stakeholders would be customers, people who pay for the product or service. And if you substituted maximizing value to something like guarantee confidence or peace of mind, then I'm not sure what the consequence of that is that addresses that green section of the penta diagram, I believe, and also as a side effect. And I'm just restating, I think what you said, as a side effect, as a consequence, you're you get profits, you your profits go up, especially if you do it better than the competitors. So I don't know if that adds anything to the discussion. But I wanted to mention that oh, yeah, no, correct. Every little thing about my mind, which is, you've heard from Musk that his ambition level, with full automated self driving is that it is 10 times safer than conventional driving is today. Notice, he didn't say 100 times safer, a million times safer. He could have that's, you know, way up there. But he's quite happy to be 10 times safer, and he reckons he'll get regulatory approval for that system. So there's an example of setting a very ambitious, very competitive thing. He's not there yet. I think he's talking about twice as safe now, or something like that, that order of magnitude, and, and 10 times within a few years, whatever that means. muskie in terms, okay. But But that's an example of, you know, mind blowing, life saving pipe ambitions that he goes after, but he doesn't say we're going to, we're gonna go for infinities. The problem is, as you approach perfection in any, you like, 100% of A, you also approach infinity in your costs. Yeah, therefore, we, we cannot have such ambition levels, they put us out of business, you know, Rose rice, finally, finish essentially went out of business by being too perfect.
Let me actually tell a story that illustrates two things, it illustrates what you said. And it also illustrates the danger of local product management. So this was I can't remember who told me this, really could mention his name. Anyway, this goes back a long ways back, you know, 1520 years ago. And he was talking about how he had a client, and he was the product owner for the client. And well, it's actually more of a more of a overall coach. But he was also acting as a product owner for the client. And they, he did something was very good. He was I think he was using Scrum. These did, like some increment of value. And then they said, Okay, what do you want next? And then the next couple of weeks, he gave them something else, and what do you want next, and gave him something else. And the people were very happy to keep giving him more requests. But he noticed that there was getting to be a diminished rate of return. So he could have easily gone down the path of let's keep getting this report. Let's keep getting this report. Let's keep getting this report. And he said, okay, yeah, I can do that. That'll get you this value. But is there some other place you'd like to work that would get more value? They said, Oh, yeah, yeah, I would. And see, this is actually one of the dangers in my mind of product owners dealing directly with Scrum teams, but without seeing the big picture of the stakeholder values across the organization, because their job is to maximize. And I think, I don't know if they say it this way. But if you look at the way it's set up, the product owners job is to maximize the value the scrum team is giving to the stakeholder. But that's not what they should be doing. It's what can they maximize? How could they greater increase the value to the stakeholders as a whole. And they might switch stakeholders, they might even switch which product they're working on. Maybe they need another product that's related to this one. So we want to always improve but we want to look at it from a holistic way. And that's another thing these five things bring us. It's not just it's not just we have to look at all five of them. But we're looking at five of them across an organization And that's what's lost. And it's lost in the two extreme examples of agile right now scrum loses it because it's at a team level. And one of the problems at the team level is it's not, you're not going to see it. And Scrum is basically you cannot make good systems comprising of individual components. Safe, on the other hand, takes the components and puts them all together, but you don't see the relationships that are present. Like, I'm going to pause for questions again.
If there are, I'm thinking, Tom, you know what might be interesting, because we did this a little bit. Now, these are order because if you've got a five things, you've got to put them in order. You ever noticed that? If I put all five of these, or Tom put all five of these on top of each other, you couldn't read it. But this doesn't mean, this is the order you do it in. Okay, I remember I tried getting time to say, what's the order we do this in, and then we shot that down pretty quickly. You know, we're both consultants. So our favorite two words aren't depends.
Can I comment on that? Oh, yeah, please. There is a logical sequence. Yes. In other words, if you don't know who the stakeholder is, you can't possibly know what their values are. If you don't know what the values are, you can't possibly know what you have to design. If you don't design you cannot possibly know what the cost of that designer. If you don't know what a big strategy is, you cannot possibly decompose it into small incremental strategies. Right. So there are there are relations which are very strong here. Yeah. Okay. On the other hand, let's go back, we have a thing in which you'll find in my various books, and I have a paper on it from Guild fest last year, about the EVO cycle, can we make a note and put that in there out? Yeah, but we have a thing called the guild EVO cycle, which it goes from, you know, stakeholder to value, to design to decomposition, to implementation to delivery to customer to measurement to learning, and then back to the stakeholder. And it is like a Deming plan, do study act cycle and eternal cycle. Or as Deming put it to me, it's eternal as long as you're in competition
I was gonna see if I can find that picture.
of it. Yeah, be great for you find it. And for the moment, I, we actually released that paper that set of slides about the the EVO evolutionary side,
that's a bit to go over in just a couple of minutes anyway, but I'll get it. I'll get it out there. Yeah. I think I've got any one of my ace slides, actually. But anyway, I'm not gonna go look for it. So yeah, there are some orders. But what I meant is you don't always start at one or the other. Although valid. If you don't know values, you can't do much, but Oh,
okay. That I remember discussing this with Dr. Deming in 1983. In the plan, do study act cycle, you know, it seems obvious that you should start with plan, you know, and then you should study, plan, do ya do and then study and then act. But And now, it turns out? That is, I made an educated guess and demonstrate your right, Tom. My educated guess was, if the cycle is long, like waterfall one year, it makes a great deal of difference where you start. If the cycle is short, like one day, which is what Musk uses for his cycles in his mobbing methods that it doesn't matter where you start, you start at any convenient point, which may be already done, or you're already there, and you'd continue. Okay, in other words, once we're in true agile, and we're dealing with a shorter cycle as we can get away with start, where you start on the cycle, doesn't much matter. It may be a matter of convenience, like we talked about this yesterday. Let's start there. It's very convenient, rather than oh, let's go to the beginning because today is the morning because that's silly. Okay, so So again, the the fact that in the old days, people had these naturally long cycles of multiple years to build, like military IT systems, then where you started was important and starting in the wrong place would be really disastrous. And starting with the costs Starting with the cost before you had designed before the use of the values before you knew the stakeholders is ridiculous.
There's another way to say this, which is, and this is a way to avoid analysis paralysis is what Tom said. And another way of saying it is you will learn more about what you have to do by starting and getting quick feedback than by analyzing for a very long time when the cycles can be short. So it's not about not being prepared, you might prepare by doing some initial work and see what's going on and recognizing maybe we didn't start in the right place. That's the heart of agile in a lot of ways.
So maybe just a quick comment, this notion that perfect quality costs infinity and therefore cannot be achieved. That reminded me on about a situation, I think the the IRS, the revenue service, they have a very limited amount of people to audit tax returns. So the perfect world to find every text sheet and audit every return, that's impossible. And they know that and so as a result, they say, Well, how can we optimize what those resources will be able to do? And so I think there's this idea of a risk stick of going after the next most likely fraudulent return. And I think this idea that you can't know, everything upfront, is so perfect is impossible to attain, you break it down into a series of smaller steps, but you have a metric that allows you to say this is more likely to get value than that one. So I started with this almost like a Western Civ or, and I think the whole notion of iterative development, and using these touristical values, that seems very fundamental to Agile
talks, I have to have a minute here, I've just been reading, I have the detail, if you email me, I'll send it to you, Thomas. In Holland, they did exactly that they use an AI system to point out potential tax cheats. And the AI system pointed out people who were of a certain racial quality and a certain economic quality, and these people were put in jail and and denied their government services. And finally, they woke up to the fact the AI system was persecuting, and the government innocent system says citizens, you got to be damn careful about allowing the government. And by the way, this is not new, we've had the same thing happen in Norway, with social security people people put in, and in Britain with the post office scandal, innocent people lives destroyed by automated attempts to say that's a tax cheat, that is benefits cheat. So be careful.
When we have points here, we have two points here. One is heuristics and the other is automating. This is where you need a loop. This is where you need this double loop. It's called double loop learning. But the first little bit easier way of saying it is a first loop is how well are you doing what you think is the best way? That's something you should be doing on a continual basis, the daily, bobbing that must does is an example that every day how are we doing, how are we doing? But on a regular basis? Maybe not every moment of the day, you have to be looking? Is this really the best way I shouldn't be working? This is like questioning your assumptions. This double
anyway. Yeah. Thomas, your your point is valid and good. Yeah, I just was scared when I now know how far it's gone into your life.
Again, this is what the reason I bring this up with what he said is people stop looking at once they get going and you say this is what you're highlighting Tom? I mean, yeah, Tom, is is that you have to make sure. Is this really working getting the cheats in jail? Or are we just following the information? I've been reading this book called thinking clearly, which I highly recommend. What's so brilliant about it is, is that it's not just about how people react and interact, how human beings are wired. And so he does talk a lot about that, which is cool, because that's what we talked about in the ACE program and the coaching track. I don't see it talked about too much. But he talks a lot about information as well that the quality of your decisions is only as good as the quality of the information you have. And all too often we get our information kind of filtered down. So anyway, we're kind of reaching the top of the hour I will get this stuff up on the site. And we haven't decided what our next topic is. Although we had some thoughts about it. But I think what we'll do is we'll announce this sooner this time and actually give you some books. So then if you want to, you can read the books that'll be relevant to that, Tom, and I'll have this conversation, I guess, Saturday. And then what I would suggest is maybe read one of his books, going into a session where we'll talk about the book that would make for a better learning dog. So, anyway, that's what we'll do. I appreciate you all being here. I really kind of feel that I'm just gonna say this last bit. I think the Agile space is at a turning point and inflection point this, I've been saying this for years in here. So I'm like Mark Twain, predicting the future is I mean, making accurate predictions is difficult, especially when it's about the future. But I'm finally seeing some evidence. You see the pulling back from frameworks, you see people wanting to do it on their own, or kind of just not even having any, which I think is an overreaction. You need some structure, but it doesn't have to be a framework. But I think what we have here is how do you get your hands on the reins, so to speak, of what's going on? And I gotta tell you, when Tom and I first started working together, I was a pretty accomplished guy. I had you know, I was at the get tenure gathering of of the Agile Manifesto, or wasn't that the first one I was reasonably regarded as knowing something about agile, written five books. Very strong, technically. But Tom opened my eyes, I did not had not read his competitive engineering much. I'd seen it I'd skim that read a little bit. But this is really a guy read his stuff. It's he's very deep thinker. And he's a lot more precise. And I am and I kind of think I'm more precise than a lot of other people, but compared to him, not at all. So let's make this more of a I like the fact that we're not making presentations. And we're asking questions for questions. But I think we can turn this into a little bit of a study group now that we've got three topics. And we'll figure out what we think is next if you want to hear a topic. In fact, we can even do that I can send out a note to the people, we get your input, and then in a week, we'll decide what to do. Okay, why don't we do that? I'll send out a note. So think about what you'd like to learn. He's probably written something about it. And anyway, I always learn a lot in these when I'm listening, you know, and it's always good for me. So thanks for being here. Any closing comment from you, Tom that you'd like?
No, but just enjoy my view of the Oslo fjord. Yes,
it's kind of jealous. I'm downstairs. I can't show you the Puget Sound but as your the Oslo Accords nicer than my view. I can show you what the squirrels getting into my peanut collection outside but that's not that interesting. Excellent. Take care. Thanks for being here.
Thank you both. Bye, everybody. Nice to meet you. I put my email in the chat.
