Okay, so we're going to use the same format as before, unfortunately, we've lost 12 minutes. But we're talking about critical stakeholders or successful using criteria, and Tom is going to say something about it to begin, then I'll say something about it. And then y'all can ask questions. So Tom, go for it.
Okay. Everybody knows that people often refer to their customers and users. And we even have things like use cases, user stories, you ex, virtual, we're proud of ourselves, we finally focused on them. But I keep people have, in my opinion, forgotten who they sometimes mentioned it, that state, the stakeholders, which is a much broader category, stakeholders is defined as any person, people or entity, like a law, which has requirements for our system that are more or less high, high priority, and we have to do them. And if you do not analyze your, your broad set of stakeholders, you could end up like Google, with $800 million fines from European Union, because they didn't consider the European Union with his privacy laws, was a stakeholder in their system. So serious building of systems requires, in my opinion, serious analysis of your critical stakeholders, and their critical requirements.
Is that it was well, I was gonna ask two things that supplement that. Okay. And you can add them to this. As you mentioned before, stakeholders are not just internal people, they're external people and FDA, like you mentioned, you know, with the union, you know, a lot of times that stuff's tacked on at the end. Oh, yeah, we have to pay attention to that. No, no, you have to pay attention to that right from the beginning. This is part of the lack, in my mind, of most of what's going on in the Agile space. Of what are you attending to, you know, we talk about in theory of constraints, full kidding, which is what does it take to get everything done? Everybody? Well, that's part of the full stakeholder success criteria is it not just get built, it goes, it creates value and returns an investment, that we're satisfying the needs of the government agencies that were have to. And the thing that's been striking, I haven't quite sorted this out fully with the topic here. But I know it's related. Which is, how do you talk to these people, if you don't have the concept of the quickest thing that can be delivered in manifest value. This is a common problem that everybody seems to be complaining about. You if say you're doing Scrum or anything based on it, you can't talk about a sprint goal. Because he's not thinking in terms of sprint goals. And sprinkles don't match with what's the next thing you could deliver. Tom's regaled me with a lot of stories where he had them figured out he didn't have a term for it, he just made it really simple. It's the next thing of value can deliver like tomorrow. But the fact that we don't have a term when it's not something you can do tomorrow, and it's something you've got to build. The fact that we don't have a term that represents the quickest thing you can do, that relates to the critical stakeholders inside and out relates to all the pieces that are needed to make it a success. I think it's a major failing in the Agile space. These are not MVPs MVPs have been defined by Eric Ries and a good way that I like and it's been misused by a lot of people. So I think the communication method we use to the stakeholders is also important and that's kind of my point. Okay, so now we're just gonna we're just throwing this open for questions.
Any thoughts on using the stakeholder quadrants that PMI recommends?
I'm not sure that's a I don't not sure I even know what it is. Okay,
it's a quadrant map, where you rate the stakeholders you know the Once you have to, oh, with the ones that you can just keep them informed. And then
okay. Yeah. upper right quadrant. Does does that relate to? Yeah, like, man, it's closely. Yeah. You're all Oops, that's not what I was. There, let me just throw this up here. No, this is this would be a classification of once you've got stakeholders identified, maybe how you manage with them. And my sense was, this also seemed to be more about the people, not as core as the executives, or as the critical stakeholders that are driving all of this. That's another piece that maybe we need to mention that we mentioned, too. But the third piece is how do you alleviate conflicts? If you don't know who's driving it from the beginning, giving it funding or the need for it, then it's virtually impossible. This to me would be more a way of man who you're who you're I guess you could put this up at the front? And how do you how do you interact with them? Susan, I see your hands up, you have something here? Just another question, we'll come back to this. Well,
this is actually related. I really find what's called the onion diagram more useful, because you can kind of update it as you find new stakeholders. And basically the people in the center are the ones who are dealing with the system. And then you have your your executives and the people who are getting value out of it and the external entities and the in mastering the requirements process. Does James Robertson and Suzanne Robertson even add what they call negative stakeholders, which are the people who would like to do you ill because you can't interview them directly. But you can think about what they would try to do or want to want to do to harm you. I
think what what we're talking about here are actually two related but separate things. And Tom, you correct me if I'm not getting this, right. There are the critical stakeholders that are actually the ones who sat what the value is on the success criteria. And as you'd say, you know, any any kind of requirements that start the thing, then some of these here, when I look at this diagram here, I look at it as well, these are important people to work with. But they're not the reason you're doing this in the first place. And so, Tom, you when you talk about critical thinkers, I always think you're talking about what's driving this? Well, how will I know it's a success? And then these are how do I support it and create it?
Shoot us and you had a remark hand up.
Yeah, one of the one of the other things is that it may just be a semantic thing. But you can distinguish between those who provide the business requirements and those stakeholders who provide their individual over their requirements for the sake that they look at. Yeah. I, I and, and in any conflict, the business requirements should win is one of the reasons for maybe mentally distinguishing those two, right?
Okay, let me become a first. That's not true. If if a government requirement and a business requirement of conflict, then you can't be illegal just to satisfy your customer. Okay, so that's, that's not true. Now, there are probably a million different ways to categorize stakeholders. And by the way, I've put up in the chat, a free stakeholder engineering book with a lot of details about different categories and things like that. And different categories will be useful for different purposes. So separating those who have business requirements from those who have other requirements is perfectly valid. I was just objecting the fact that when there's conflict, business cannot win against law. And I'm sure you agree with that. In principle,
yes, I know I do agree with that. I would say that in a higher level. If you want to stay in business, you actually have to obey the law. So you could call it the business requirement. But there's
a more general interesting thing there, which is that conflict between stakeholders is inevitable, and pervasive. And we don't say, Oh, I won't do that, because there's conflict, although I actually find people who say things like that can't do that it's in conflict. But we have to learn to resolve the conflict, the classical way of resolving is known as prioritization, you know, and to the point of exclusion of some things, which are very low priority. And I write a lot about how to prioritize was another subject I think we're going to return to later but I write about it a lot. me start again, because there was another thing was brought up is about critical stakeholders. Now, a critical stakeholder is defined by me as somebody who some some entity that has a critical requirement. And a critical requirement of using the word critical almost in the medical sense life and death. Okay, critical disease, your mortally wounded. So a critical requirement is something that has a very high priority, because if you don't do it, your whole system is at risk. Okay, so in other words, our first order of business is to take those things that have the highest priority, I mean, you have to do all the critical things, or by definition, one of them might kill your system, or make it illegal, or something like that. Okay. Now, having said that, that the most important business is to figure out the things that will kill your system, and deal with them. There's a whole lot of other stuff, which won't kill your system, but it might reduce your sales or your profit, or the success of a government endeavor or something like that. And so that's another class of requirements that we have to analyze from the stakeholders, you know, the things that are not life and death critical, but are important for success of our systems. By the way, as the book I've just given you access to proofs, I've got an awful lot to say about the subject, which won't even get said, Even if I were to take over the entire hour. So when I shut up, it's not because I don't have Word and save, because I want you to let you guys in of course. Yeah.
And I will put those on the site where we have Tom's books, I'll add these there.
How are you feeling? Susan?
It kind of sounds Tom, like you look at risk management alongside of stakeholder management.
Ah, that was an Toki. Right ahead, a window over so yeah, very much. So now, let me take a little dive into risk management and, and owl, I think that's a separate topic.
It is a it's funny, because yeah, you talk about it. Okay,
so quite a few of my different books have pulled chapters of like 70 pages, just on risk management. So I have a lot said, but I'll simplify. What I found is that absolutely every little detail in systems planning, like every aspect of requirements, every aspect of design, every aspect of stakeholders, is in fact managing the risk that something will either go horribly wrong, you've forgotten a critical requirement or critical stakeholder in your system is illegal, right? Or it can go partially wrong, you know, lower profit or something like that. So, so yes, everything about stakeholder management, and I have over 100 pages on the subject in front of you, I think I forget the exact page number. Everything I say about stakeholders, there is risk management. So if you want to, you know, advanced risk management education, you would go through that entire stakeholder book in detail, and that is one part. Then you have another topic like requirements, which deserves the same detailed attention, and I have detailed writings on that. And then you have design, and then you have management of teams, you know, so on. So, absolutely. It's just seems like absolutely everything we do and have to do to make our systems. However small and trivial is related to the idea of if you don't do it, or you don't do it, well, there is a risk that something's going to go wrong. So in simple terms, everything is risk management. And I like to take one trivial example to prove to demonstrate make my point a little bit more dramatically, in my way of specifying everything, which I call planning language replaying which there's a thing called a tag, which is simply the name of the requirement or the name of the design, or the official name of the stakeholder right now. Having a tag or a name ordained doesn't seem like a risk management thing. But think of the opposite. Think of how often we see things with bullet points. And no names whatsoever, you know, the main requirements are that what does that mean? It means nobody's going to track and trace and follow up on those, they're gonna disappear off the slide, and they will be forgotten, and nobody's gonna do anything about it. Okay, so by putting a tag on something, it's a little signal that we intend to define it. Well, to keep the definition of it up to date, when the stakeholder nature changes, we will change the definition of the stakeholder object, but it will have the same name. Okay. And through the lifecycle of the system, we can track and trace that we're doing things as intended and as plant and so this little trivial detail, having a tag. And that means a digital tag that is there for the long term. Okay, not just on a set of slides one day. That is, in fact, a very good risk management idea. as trivial as it sounds, you know, it's one of the 500 things we could do.
What would be kind of like an RTM, right, traceability matrix?
Yes. Very good. You're in this in the right area. Tags allow traceability and lack of tags makes things terribly difficult to trace. But it's just an example of something that seems trivial. If I talked about a tag on something, nobody's thinking this is a risk management method. But it is, and people who don't tag which are, it turns out, if I take a look at somebody's description of their system, let's say a top management description of the major objectives and the major strategies, you find bullet points all over the place, but you don't find tags. Now, that tells me right away that nope, these managers are not taking these things seriously, and making sure that they're well defined and well followed up and well changed, by the way out, I just held a lecture for Linda Westfall, in Texas on configuration management. Okay. And I think I'll put we're talking about configuration management now. And I think what I'll do is I'll put the link to the slides in the chat and we can we can put it on the other things out there. I'll shut up well, I put the my completely new configuration management set of slides. Let's see meeting chat. Okay, that's a good thing to have. And but I'm going to stop talking while I put that on there.
I'm pausing for questions to people
no one has one I've got one for you and not Tom for the participants. I I'd like you to reflect on how the product management product ownership roles in Agile help do what Tom was talking about and work against what Tom was talking about. In other words, the roles roles as defined is it's kind of part of the system so it can be a positive or negative thing and I'm wondering what your all's experience with the roles as they're commonly used in the Agile space are helping or hurting
Well, you know, if you can think about stories and consider them your requirements. Everything is knitted together.
How is it knitted together?
You have a system like what your business analysts used and you kept every requirement defined And, yeah, and you can automatically produce RTO limbs and feed risk management systems. And
that seems to me that it would drive just up to the business analyst. I wouldn't go any further behind. Beyond that. Susan, do you want to comment on this? Yeah. Why don't you do that? We'll just have a three way four way conversation?
Well, what I have found is that the way that most people use user stories, and I can't claim to have ever been in an ideal agile implementation, or even an ideal other implementation, but things like user stories and requirements, saying that this is missing, and, and things like that, that are often done. As time goes on, while you're thinking about it, often failed to look at the whole big picture of what you're trying to do. And so I have seen, yeah, I've seen situations where the bug reports or user stories, where somebody says do something and then somebody says, do something else that contradicts what you do there. But you don't know that because it's just all a bunch of items that that don't have any larger integration to.
Just put in the chat, do we need different kinds of stories? I mean, that's the whole point user stories, immediately in our language, focus on users. If the people when I wrote software I most listened to I listened to the users. I said, the look and feel of the system. But what the system did I talked to the owners of the place.
Good, good point. Just for fun, I'm gonna coined the term stakeholder stories. Yeah.
Yeah, actually, I used that term before, but it was inspired by us. So you can coin it, okay.
Okay. Now, here's the stakeholder stories. I think Susan is right on the money there, that they they have a kind of narrowness to them, they don't pervade the system. And so let's take a simple example, if I want to enhance the security of the system, by a whole lot, okay. I don't really write a user story about that. The user story is really designed to give a programmer a way of programming, some functionality, my view of it, but security pervades the entire system. And we call these things qualities. And when Mike Cohn, the Mr. User Story, friend of mine, was asked on his website, what do you do about qualities? And he said, I would refer you to Tom guilds, language methods for articulating qualities. Now, when I had, I actually went back to Mike and said, Mike, let's you and I talk about extending user stories to deal with quality. And he said, Oh, I'm too busy. And it never happened. But we, you know, so user stories are as soon as and I think he's pointing out inadequate for certain classes of requirements, like all quality requirements, and that's a big miss, put it mildly.
You know, just sagging off that. It hits me that NFR RS might be a symptom that we're missing all of this. In other words, there's this focus on the functionality, but insofar as are just as much critical requirements as the functional requirements per se, like security, you know, they talk about that. I put us in the chat. And I'm just actually speculating that that might be a clue the effect that they're separated is not necessarily a good thing. And there's nobody responsible in Ace, basically the product management of Scrum. For the entire requirements stream, you know, the product owners they are they figure out how they do it. And then from their point on the team works with them with that little exposure to other things. Now, and I wanted to come back to you though, have we answered your questions or concerns there?
Oh, yeah, no, I'm fine. Okay, good. Yeah. It's all a milkshake, right? You put in the glass, you shake it, and you're either gonna get chocolate or vanilla, you know, but it's all you know, you can't have a test plan without an RTM is either agile or predictive.
No, but lots of people find you.
Yeah, but because the right criteria needs to be spelled out at a requirement level in order to have traceability.
Well, let me ask you this question. Again, in general, what are the challenges you see, as they show up? You know, like the situations people find themselves in where it's not working. And how widespread are those?
I'd say it's pretty widespread, because very few people have the diligence to do this stuff properly. You know, we're all we're all caught up. And then you have this big system in the cloud. And all of a sudden, AWS needs to make a change in the in the cloud, and you don't have a test plan to do your Dr. With because you never have defined the requirements for the cloud.
Yeah, yeah. To me, this is the unstated mental attitude that you can start with a team, then grow a process out, and that somehow you end up with something that's holistically designed. I mean, it's grommet scale of that regard is almost an oxymoronic statement.
I would agree.
Let me feed off of that. The way Absolutely. All projects it and not it. If you look deeply at them, and know how to analyze them, you'll find something to be true. They are not about implementing functionality. That's sort of a given. In a given. You know, in banking, you have functionality, quality, interest, computation, right? All projects are about improvement of something. And that's something we have a name for it. It's stakeholder values, which include all qualities, and costs, which include short term and long term costs, all projects primarily deemed to want to enhance values and qualities, and or reduce their costs. And the functionality is just something you have to have in place to do it at all in the bank. Okay, but it doesn't make a critical difference. And we don't many people misunderstand this, for example, they'll say that we're gonna have a corporate trance agile transition, you know? And what's that? Well, sort of sounds like a functional change. But if you go a little bit more deeply, why do you want a corporate agile transition is to improve stuff in the corporation, their competitiveness, and their profitability and things like that. And so because because of the part of the problem is, people have not learned to articulate these qualities and values above highly ambiguous statements, we want higher quality. Okay, they don't know how to measure the quality. They don't know how much they want, and when they want it, okay. They that they know how to articulate it with words which are so ambiguous that nothing happens. Nothing can happen. You can't test it. There's nothing to test. If I'm going to move from 60% security to 65% security for a hacker intrusion. That's a miserable idea. That's a miserable security idea. But just saying I need better hacker perdition of the word better, doesn't give you a degree and Hacker Protection isn't well defined. Okay, so this is a big problem after finding your stakeholders who have some power over you to impose requirements and that is to articulate the the value requirements I prefer to call them. We know how to articulate cost requirements. Everybody can do that right are reduced by cost per year by 10%. But what people don't know how to do is this really important area called stakeholder values, okay, which include all of the qualities of the entire system. We are not taught we even say it's too difficult. We deny it can be done or we make excuses like it's too costly, all of which is false. And I think one day I'll we're going to have a special session just on the stakeholder values and how to quantify and clarify. But you will find this in the things I've handed out already, like this takeover engineering book, you'll find examples of doing that if you want to get ahead of the game here.
Other questions, I'd rather wait for other things from y'all.
I would just say that one of the things that happens when you have these better quality type requirements is that people will resort to saying, Okay, and do you want fries with that? They don't. They don't even begin to try to question what that would mean.
Yeah, well, it's like a holistic view. How did the fries fit in?
Yeah, well, that matches to your remark, which is sadly so true, that people are not willing to learn or apply a appropriately serious discipline with regard to the consequences and complexity and size of their systems. You know, they they treat things in a fairly amateurish way, which may have been good enough. 40 years ago, when we were writing small programs for small computers. Okay, but now we have like worldwide International, millions of people systems we're dealing with. And my theory of this is, we've got to do what every other discipline has had to do move up from the craft level, I am a coder to an engineering level, I'm going to build a pyramid.
And that's a bitter pill for people to swallow, who, for example, do not have an engineering education. And Derek, good coder, bless them, we need good craftspeople. But at some level, things don't work if you don't have a systematic way of putting the complex systems together. And that's known as engineering, and it had higher level architecture. And we're just not good at recognizing it and doing it. And we wonder why the IT systems fail. And part of the reason is, we're not engineering. We don't quantify things like security is what that means. And we're not architecting we don't know how to take 10 Different to cure 10 different qualities, and 10 different cost aspects, and put them all together into one picture. That's architecture. We don't know how to do it. I know how to do it. It's in the books I just gave you. The happy to teach you. But somebody has to want to do it, want to study it, and want to practice it. And right now we're getting away with very poor systems. And when we blame things like we're not agile enough, or something like that, but nothing to do with it. But about we're not engineering enough as an excuse. That's a better excuse, in my opinion.
By the way, I have a I'll put it in there. I have a thing called Agile engineering. Hmm, fun. I'll put that in there. Having broached the subject?
Well, that's even the picture you're painting tongue. You have really big companies that don't even have a requirements management system. They're doing it in Excel for God's sake.
Right?
How are you good to check all this stuff in overtime, update it to her, it reflects reality, you know?
So yes, you're right. It's horrendous. It's scandalous. Now, if, if more of the managers, the Chief Technical officers were brought into court as responsible for not having put better systems in place, people might begin to take it seriously. But right now they get away with saying, Oh, well, we could have become more agile or something silly like that. You know, and people said, Yeah, we need an agile transition. So we'll do that for the next four or five years. And they don't even recognize that the fundamental causes of failure is not agile are not agile. Agile is a good thing than property. By the way, it is a lack of engineering for complex systems. Anyway, I put the Agile engineering thing in the chat. And I'll we'll make it available. But if you want to know what Agile engineering is, which is a fascinating question, what is agile engineering? Then I've detailed it. That's what I do. And by the way, I've taught this to some very fine engineering companies like Intel, Hewlett Packard, Ericsson, and dare I say, at Boeing and McDonnell Douglas. They like it, because they're engineers.
You know, Tom, I was half expecting you to bring up Val plan, it might be worth doing a session on because that tool is, don't use it, it brings up so many interesting facets. Okay,
let's be careful, I agree with you. But let's be, by the way, Val plan is an app, which implements my planning language. So it's got quantified, that quantified values and qualities all over the place. It is a separate subject, but we get to we shouldn't go any, you'll find examples of it in my books, and talks. Okay. But let's not go go there.
I didn't want to go there. Now. It's I agree, that's a separate thing. But here's you may have seen I was writing some things up on the screen here. You know, I think, in the Asus program, I talked a lot about languaging. And people's listening also in the coaching stuff about how we create our reality. But you know, this comment by Edgar Schein, we don't think and talk about what we see, we see what we think and talk about I think is a more pervasive limiting constraint than we give acknowledgement to. And I know both just to make a clear statement here. Tom and I neither of us are fans of the Agile Manifesto for any number of reasons. Tom wrote a really good critique of it. But the only response I saw from a lot of agilus was Why is Tom guilds so mad? Which happened, right, if there was no anger in it, it was just this dissection from a very objective way with no emotion or anything. I mean, I am guilty of that. You can say why is Al Shalloway. So mad and guilty? But But Tom's not that way in this article isn't that way. But what's really hitting me as we've been talking? I've been thinking about like the roll limitations and things like that. But a lot in the Agile space, even when we were when we did large scale things that objectives. I mean, working with large companies, we didn't have roles defined, what we did is we had responsibilities. And then we would look to see who would take on those responsibilities. And then maybe we throw name, well, that's called the sort of calls to the product owner, Product Manager. But it's a list of responsibilities. But anyway, I'm a little off track there. Let me say what I'm thinking. The manifesto, it's not so much that it doesn't have systems thinking, which I've complained about in his why I didn't ever sign it. It's not so much that it's focused on the team, not so much that it's focused on software required on software, not so much all these shortcomings, which I've laid out to him not as succinctly. I don't I call it succinct. I'd call it more accurately, it's time that he was kind of long. But But I think the real danger maybe is just that it presents as a certain mindset of thinking, not a mindset of what you do, but what you're looking at. And the manifesto creates a filter through which we view everything and I think Scrum has taken that on and now between Scrum and XP, it's just that's the way it is. And then you have safe as an outlier, which is the big thing, but less than scrum at scale. And all those guys are all team up approach is disciplined. Agile was a different approach. But that's also never made much headway. So I'm wondering, and I'm not saying to do this, but I'm curious what a manifesto based on business value realization would look like. That that could be a different thing. That might be an interesting exercise. And in fact, in fact, it See, I never wanted to redo the Agile Manifesto because manifestos are for a time in place, and it was a good thing. I mean, I'm not I never claimed, if had I been there, it would have been better because of me being there. never claimed. But maybe, maybe that is is an interesting exercise to have it as just a little group discussing or maybe on the ACE, LinkedIn group. What are any thoughts on this? Not so much to do that, but how does the languaging the speaking of the manifesto kind of warp everything we're doing not so much the principles themselves, but just what it presents is
a try short remark. Well, other people who are thinking of it, they, the manifesto has words in it, like value. But they, they don't define it. And they in particular, they don't define it as a non financial values. This was the problem with Balanced Scorecard in its time, it wasn't balanced, it was over financial. Okay. So in other words, they give lip service to the key ideas, and they didn't ever do anything about them. They're so we're failing. We've, you know, we said liberty and justice for all. And then we go and screw things up in the liberty and justice area. And we haven't even agreed what it is. So my, my problem is that they're, they were capable of naming good ideas, and not capable of making them happen in practice with specific technology. So I put my paper that I'll refer to how well does the Agile Manifesto align? In the chat? You
know, this is this statement, I just really hit it. See, I really do need to come back to this because Because see, I read this statement that at regular intervals, the team reflects on how to become more effective than tunes and adjusts its behaviors accordingly. And I just took that as a team focus. But the problem isn't where the focus is. The problem is what's being filtered out. The two go together, obviously. And everything we've talked about here is being filtered out. By the way, Agile does things and how do we expand the filter in a sense? How do we look at the right thing? I think this is actually an important piece
things are happening. Yes, it things are happening. The many years ago, approximately 2007 Chess oven, which here in this living room you're looking at right now. And he took a look at what we were doing with one of our clients called confirm it little Norwegian company, but they were doing multiple qualities and multiple costs simultaneously in weekly increments. And he said, this is fantastic stuff. I want to add it to Scrum. Okay. Now, fast forward. Even though he wanted to do that he was out voted by somebody wanted to keep Scrum, simple, and not add anything. Like you'll notice it doesn't have any test procedures and things like that. There's an argument for that, too. Now, so in a sense, it got censored. Now, here's the good news. I'm going to keep this a little bit anonymous, but just announced it for fun. One very good friend of mine, who is a major scrum teacher internationally, has gotten specific permission from scrum.org. To teach my methods, in addition to Scrum, they're adding the quantification of quality and stuff in there. They've recognized that it's about time to do that. So that's an experimental thing with one teacher, if it goes well. It will become official at least@scrum.org. I have to say this space used
to keep it simple, like not add something as if that makes adding something makes it less simple. If I take a tire off my four wheel vehicle, have I made it simpler? Now this is this whole thing about simple. Yeah, I do see that Thomas but you know, business people and developers, but the question is, who are the business people who are the business people being referred to in this document? And when you talk about it now everybody says, oh, that means the whole business and front end the critical stakeholders. And that's not what it meant in 99 to 2001 when this thing was formulated, what it meant was, who's the sponsor of the project you're working in? That was the business people they were talking about? Never went beyond that. So this is some of the ambiguity ambiguity can work for you because when you say it wrong, and it's ambiguous, you can say, well, this is what we met, even though at the time when we're talking, that's not what anybody said. Right? I don't think this is just my opinion I basis from 99 to 2001. Before the manifesto came out, there were a variety of us. At the time, it was on the XP XP programming group. That was where agile kind of started was there. They didn't have the scrum development group. Yeah. Which can create soon after that. Scrum came into existence. I know it was defined in 95. But it came into any awareness, so to speak, as a result of XP being difficult to get anybody to implement because of paired programming and tests first, well, let's do Scrum. Because you don't have to do those things. I'm not saying that was a good idea. And I'll plead guilty to having said that myself.
I put up some links to my writings on simplicity. But it as you indicated, we'd have to define what we mean by simplicity before we decide whether things are simple or not. And that is non trivial. Now, that's true. I've done it. I've done it in in my simple, free books, simplifications, ideas. There's a free link. And you can consider my attempt to define simple, which is non trivial. Yeah. And maybe you've got some improvements.
Well, there's another interesting thing. I had a lot of conversations with Ken and Ron about what simple design meant. And they all they both agreed that this there was a phrase, all things being equal, simpler is better. And everybody left off, all things being equal. I mean, they didn't they knew this, but it was like so. So like, fewer classes was better, because that was simpler, but it caused other problems. So then all things aren't equal. You can't do that. Now, well, this turned into being an interesting conversation, it was a little concerned, sorry about messing things up. I'll fix that what happened. And you know, I kind of like using this video this way. For reference, we're trying to figure out if it was good, I'm not sure people's faces will show up and trying to get that, but I haven't figured that out. So if anybody gives me some help through, that'd be great. We'll see. But I'll get this produced. I'm gonna have to create a special page for all this stuff. Because the book part you have is expanding. I'll figure that out. And I'll let y'all know this will be up early next week. And Tom, I can't find the list of next week analysts. Do you remember what the next one was supposed to be? Of course, we can always adjust. Any?
Yeah, I I don't remember without looking it up. But doesn't matter. I think we have time to go to values and qualities. Yeah, because we've into that, you know, the, we start with stakeholders, but then we derive the qualities and values they want to have. So that's the next and we the trick is to do it properly. Not with a highly ambiguous statements, you know, more user friendliness. That's not good enough. Or even worse, which I've heard many times more user friendly. This like Microsoft.
Any requests from y'all listening is what you'd like Next, we did have a sequence they'll find it but we're open to changing it. Nothing pressing.
It doesn't matter because your questions will drive us anyway.
Yeah, that's true. Okay, well, I'm gonna have a theme. Pause this and and thanks for being here. I'll get the confusion fixed. And we'll see you in about four weeks. be another one. Oh, good.
Bye bye from Norway. This is this is my Norwegian knitted sweater by the way.
Yeah, this is knitted in 1960 by my dear wife, both the good quality products take care
