Join Murray Robinson and Shane Gibson in a conversation about Software Metrics with Tom Gilb. Tom Gilb inspired the authors of the Agile manifesto with his innovative incremental and scientific approach to Software Engineering. In this podcast we talk about Evo and Value Agile. Defining your scope with objectives and success metrics. How to measure anything. Why feature backlogs are a waste of time. Being laser focused on outcomes. How to deliver as much value as possible in the time and budget available.

Read along you will

 Shane: Welcome to the no nonsense podcast I’m Shane Gibson.

Murray: And I’m Murray Robinson 

Tom: and I’m Tom Gilb

Murray: Hi, Tom. Welcome to the podcast. , We wanted to talk to you about Evo and value agile, which are your methodologies and books. Could you kick us off by describing your background and experience? 

Tom: I started working for IBM in 1958 at the rip old age of 17 in Norway. And very quickly I became a consultant and then international consultant. I’ve effectively been that ever since. So I have a wide variety of experience in major corporations, all around the world. The likes of Intel Huett Packard, IBM Erickson, et cetera, and spread my methods mainly to leading edge corporations rather than the masses. I’ve written a lot of books. In 1976, I wrote a book called software metrics. In other words, measurement of software qualities. And in it, I also described early versions of Evo, which by the time the book was published in 76, I’d had 16 years of practical experience doing.

Murray: I have heard of EVO, people like Jeff Sutherland and others have said that they see it as one of the precursors to agile rad and design thinking and some other things. If I understand Evo you focus on the requirements, design and decomposition part of the systems engineering, process. 

Tom: That’s right. Now when many people say requirements they’re thinking usually of functional requirements defined as what the system must do that you can test, does it do it? Does it not do it? Some of them are thinking in terms of use cases and user stories as a precursor to understanding requirements. When I say requirements, I’m thinking of all types of requirements of which there are many. I’ve cataloged and defined about 20 different classes of requirements, for example constraints, qualities, costs and functional requirements. What I’ve learned is that if you ask any executive team, why are you doing this project? They’ll come up with an answer, that answer will be what I call value requirements. We’re doing it because we need to have much better security for the system. We just got robbed by some ransom guys. In fact, they’ll give you a series of reasons. Every reason they give for why they’re investing in this project, turns out to be what I call a value. And many of these values are what we would technically call qualities such as security, usability, flexibility and things like that.

So what I’ve learned is the primary drivers from an executive and investment point of view of any project seems to be the values that people want. The functionality is a given it’s the business you’re in. You have to do that of course. If you’re in a bank you have to have interest calculation. That’s trivial. But the main reason for an it project is to enhance some of the values. We needed a much more flexible system or a system that could expand faster or a much more secure system.

So what I’ve learned is that the primary drivers of projects are in fact, these values. Now the problem is the executives will tell you, they need a hell of a lot more security, cuz they just got robbed. But what they won’t tell you is exactly how much security they require. And that’s where I come in and say wouldn’t it be nice if we had a clear idea of exactly how much security we require, wouldn’t it be nice to put a number on it so we could measure how much security we have.

And how much security we require before the project is successful. That’ll give everybody some clear ideas to think about. It’ll give the architects a clear goal for what kind of architecture they need to have to reach a specific security level in a specific time. Now that’s what people do not do.

They actually stop at the bullshit level and then they dive in and they do all functional requirements, often mirrored by user stories and use cases. And they program them all. And then the system doesn’t have the security they required.

And the simple reason is they never clarified exactly how much security they needed and they never architected the system. They just dive in and chunk up the coding into epics and stories and things like that. So they’re doomed to not achieve any interesting quality or value that top management thinks they’re investing in. 

Murray: how do you measure something like security as a valuable objective? 

Tom: The short answer is you use your common sense. One way to do it would be the percentage of times we catch a hacker. There’s a very simple notion. Now obviously it can be much more sophisticated. The percentage of times we detect any kind of intrusion, not just hackers, it could be an intrusion from an insider who’s not an outside hacker. This is called building a scale of measures like miles per hour or something like that.

And then you could add things like first there are different types of intruders, but there are different types of threats and there are different types of coping in other words, to detect, correct. What you do is build a scale of measure, which defines the security notion. And then I put numbers on it and say okay, where are we now? We’re certainly less than 5% ability to catch anything, cuz we’ve never tried. That’s ridiculous says the chief security officer, we have to have a hundred percent or the board of directors won’t accept it.

Something about the future goal is gonna be way high up there. Whether it’s 95% or 99% often becomes an economic question. If it costs 50 billion extra to go from 95 to 99%, you might just suffer the penalty of the hacker and pay him. I have a book I will share with your listeners called Quanteer. I’ll give you a link to it. Quanteer is a book that describes exactly how to quantify any variable. What I’ve found is all values that management aspires to are variables. You can always say enhanced security, improved user friendliness, and the fact that you can say enhanced and improved proves it is a variable. And if it is a variable and you understand it, you ought to be able to define some useful scale of measure. And I’ve found since the 19 sixties that I could always do it without exception. Nobody can feed me a value of quality that cannot be modeled. My 1976 book software metrics was chalk filled with how to quantify any variable . 

Shane: So have you found that there’s a common set of patterns that people who are starting out should measure first? Are there a common set of value requirements, that can be measured or do you find that each one is unique and needs to be crafted or engineered uniquely. 

Tom: Now , there’s another book called competitive engineering from 2005 I’ll give a free digital copy of two your listeners. It has a chapter on measurement. Now in that chapter, you’ll find the common things like usability, integrity, security. And you’ll find a predefined ready, made scale of measure, which you can simply use as it. All it projects have a lot of things in common and can use off the shelf scales of measure without any invention, and I’ve published them. And I’ll give that to your readers now having said that when I’m working with an industrial client, We almost invariably for every value will tailor make them, we’ll say what kind of people are involved in your corporation?

What kind of situations occur with your kind of product? We in fact that it’s very important to, to tailor, make the scales. So they reflect the business accurately and recognizably. That vastly improves the understanding of what you’re tackling and what you have to tackle. You just get it right. Again, there are three stages here. One is just. The bullshit level we need enhanced security. Total bullshit has no meaning. And then the other is to take a standard off the shelf security scale, which at least gets you thinking about this in a clear way. And then by enhancing it you’re reflecting what the business does and has to do, and you’re more likely to succeed as a result. And so the Quanteer book that I referred to gives instruction on how to tailor, make the scales of measure. So they best fit an enterprise or business. 

Shane: . I like that idea. So we had a previous podcast. We, one of the terms that came up was this idea about customized with context. You can get some things at a good starting points, but you still need to customize them with the context of the organization or the people or the industry. 

Tom: Good. I agree 

Murray: So Tom are you proposing that the scope of projects be defined by these measurable values rather than by features? 

Tom: Yes, absolutely. So features is something I ignore. completely and you will not find it in any of my writings. It’s marketing talk, stuff , you should get excited about and wanna buy our shit, that kind of thing. The feature that management wants are these values. They want the enhanced security, the enhanced usability, the enhanced flexibility and things like that. And they will articulate that very clearly and immediately when you ask them. They’re able to name the problem, the security, and they want a hell of a lot more, cuz they know it’s poor, but they’re not normally trained to a scale of measure and how much they want, that needs to be left to a requirements engineer to take what I call their ambition level, which is their blah, blah, blah. And turn it into a scale of measure and points on the scale, which become the departure point for systems engineering. 

Murray: I find the first thing that happens in projects is that we start off with some sort of discussion about what is it you wanna do and why do you want to do it? And there might be a short discussion about measurable objectives. And then it rapidly turns into a long list of features and requirements. And then that’s what the project managers focus on. So as they go through their project, all that they’re doing is trying to tick off features . And if, as an engineer, you were to say to your project manager the customer wants this feature because they’re trying to improve usability, but the way we are implementing it is gonna reduce usability. But if I did this other thing, it’d be more usable, can we do that? They’ll just say no, cause that’s not the feature we agreed to. Theat would be a scope change. 

Tom: Yeah, let me go a little bit deeper into feature. When you take a list of these features and analyze them as I do with another booklet, I’ll give you called plan analysis. And, what I do is I analyze these statements. Now, what people often do is they don’t know how to say how secure the system will be.

So they put in what I would call a design or an architecture instead of it, they say let’s use Microsoft’s approach to security. Now that is an architectural design. Now they don’t know how much security Microsofts approach will give. They don’t know if that is how much they need, cuz they’ve never sat down and said, wait a minute, before we discuss Microsoft’s approach to security, maybe we should find out how much security of what kind we need.

And then ask the question. Will Microsoft’s security approach, give us what we want. Yes or no. Now that’s what I call architecture. You start with the value in this case, better security for the systems in the corporation. And after you have clarified that with numbers of how secure we need to be, then you bring in the design options, the architectural options and say will that get us to where we want to go in security? Yes or no. Often the answer is we don’t know, Microsoft doesn’t even know. They certainly won’t guarantee it at a fixed price. So what we’ve gotta do is maybe start bringing in in an evolutionary way, some powerful, promising security options, plug them in and measure how good they are at security.

If they’re good at security in the direction we wanna be, we keep them. If they’re not, we dump them. So in other words, we will evolutionarily try out or test if you like a design or architecture in relation to the values we are seeking. Not whether they work, we don’t test and say, did we plug in this Microsoft idea correctly? We plug it in and say, did it give us the security value we want? Which is a totally different question. And it’s a design question. It’s an architectural question. 

 So getting back to your question, what you call features are often somebody’s way of saying, I don’t really know how to articulate security. And , I don’t even know that I should articulate security, but I’ve been to a Microsoft seminar and learned all about their security methods. And it sounds good to me. So let’s have a feature called the Microsoft security set of ideas. What they do is they actually give you as a requirement, a design for values they haven’t even articulated and agreed on, which is nonsense, illogical, stupid bound to get failed projects.

Shane: So, I work in data analytics, and we’ve always struggled to do architecture in an iterative way. We’ve tried to iterate the architecture as we go. As we got more things that we needed to meet, then we would rearchitect at that time. Because it’s hard to get people to articulate the criteria that drive our architecture we would often take patterns off the shelf. In the data space, every time I work with a customer, the first thing they say is we need real time data. And I’m going, what do you mean. Real time data? What do you mean? No, no real time data. So you talking about when a person at the front line is talking to a customer and they’re providing some information to that customer, as they’re saying those words, we can change that information on them and they can say to the customer, oh, sorry. It’s 52. Oh no. Sorry. It’s 56. Oh no. Sorry. It’s 43, is that what we want? They go, no. So we don’t want real time at that level. So I think what do you actually mean? Why do you wanna do this? What are you gonna use it for helps us, but it’s incredibly difficult to get measures. 

Tom: It is incredibly difficult if you don’t know how, if you do know how it’s incredibly easy, 

Shane: And because a lot of us haven’t been trained how to do it, then we fall back to the easy words, it’s something like SLAs, service level agreements. What do you want? What’s the impact of 99.9% versus nine five? The one I tend to use is, okay, so if I give you 99.95, I can be down for the whole weekend. No. Oh, so that number are relevant. What’s important? How long can I be down for how much data can I lose? How late can it be? There’s a whole bunch of measures. . So what you’re saying though, is that it’s not hard if you know how to do it. The key problem is nobody’s been taught to do it.

Tom: Yes, clearly not. They’re not taught at universities, even engineering universities to do it.

Shane: Yeah. The true engineers, I know, where they engineer bridges or engineer electricity, widgets. They know the amount of ohms or whatever, it’s gonna go through it. They know what the minimum, the maximum is. They know what they need what the requirement is, what bad looks like. When we add the word software in front of it, we’ve lost a lot of that. I think site reliability engineers are bringing in some of those practices, but in the data space we’ve got worse. 

Murray: By the time many of us get involved in projects, somebody else has already made a really long list of features and requirements that they want. Particularly if you are in the business of building software for other people, and you’ve gotta respond to tenderers, there’s always, there’s really long list of requirements with some vague value statements. Even inside an organization, you might get engaged at the point that this stuff is all supposedly done and you get presented with a long list of features. What do you do then? 

Tom: Well you’re screwed. The project is doomed. What I did was I got in the business of the very, very front end. I very often had my assignment after a major failure where they said, nobody in our organization seems to know how to do this. And we’ve heard Guild that you rescue doomed projects talk with us. So I have an hour with the top management and at that point I say what is your most critical value that you have to get? And they might say flexibility with regard to services. I say, fine, let’s write that down. The second thing I do in a management meeting like that is I say would everybody hear write down exactly what is meant with flexibility of service. I call this the ambiguity test and you can guess what happens. They all write down different things. I key them in and put them up on a screen, all 10 versions. And I said, gentlemen, we have a problem. None of you agree what flexibility of service meets what do you think we ought to do? Now? I know they know we’ve got to agree on the meaning of flexibility of service. And I said, we could define a scale of measure. They say what you can define a scale of measure. We’ve never heard of that. I said, here and now in the coming half an hour, I’ll challenge you to do it, but if you can’t do it, I will do it. And you will see that there is a scale of measure for it. And we can do this for all of your values. They get really interested cuz nobody ever taught them, how to do that. In other words I literally put myself in the business of being a proper front end to find out top down what this was really all about. the situation you present, you can code that stuff, but it’s probably all the wrong stuff for the wrong reasons. Therefore, failure is inevitable.

Shane: So one of the things we try and not adopt is big requirements upfront, we tried to not spend six to nine months writing down a whole lot of detailed requirements. 

Tom: I wanna make an immediate comment on that and I’d like you to continue your question afterwards. So I have a process of starting a project, and on the Monday, the first day of the project, often with the top executives, cTOs and people like that, I say we will establish and quantify the top 10 most critical objectives by the end of the day by five o’clock. So we start off in the morning by brainstorming about 20. We quickly pair them down to top 10. We’re not gonna forget all the other ones. We’re just gonna prioritize and do them later. We then divide into teams and I teach them how to develop scales of measure and teams of two people take one, two or three of these, and with my guidance and coaching, by the end of the day, they have quantified all top 10 and we put them on one page. On one page or one slide , we will have the top 10 that you executives are responsible for and agree to, and they will be quantified. And we do it absolutely every time without fail. I’ve been doing this for decades. So the of requirements, you know what, all that other shit ain’t requirements, it is actually design. 

And what do you think we do on Tuesday of this week? Let me tell you, we brainstorm the top 10, most powerful architectural ideas they can imagine for reaching these. And on one page, we end up with the top 10 suggested architectural ideas. In a sense, we’ve done the first draft of the architecture. It remains to be detailed and tried out and get feedback and measure and all that stuff in sprints. But we literally do the architecture on Tuesday on a page. Cause what you need is 10 big ideas like use Microsoft security is a big idea. It might be the wrong idea. But maybe with a little bit of adaptation and it’ll be good enough to meet our security requirements probably is. We need the big architectural ideas now, you don’t do that with the CEO in the room, but you may do it with the chief technical officer and the chief architect in the room. We bring different people into the room on the Tuesday, who know something about architecture. 

On Wednesday we build what I call an impact estimation table, where we take a look at the top 10 strategies and their impacts on the top 10 values. We estimate how good they are. And we try to make estimates that say, it looks like we might have enough roughly. We don’t know and we could be wrong. We even have a safety margin factor. You overdesigned by a factor of two. So if you’re wrong, it probably works. This is engineering, pure engineering. Wednesday we try to get through the table, a sense of, it looks like we’ve probably got more than enough architecture to get to our goals. 

On Thursday, I ask an incredibly simple question. What could we really do next week of some of this architecture, some small part of it to our current system. So that we could see if it works and enhances security a little bit. This team will come up with five or six really good ideas of things we can do next week, which will give measurable feedback that we have in fact, improved our current system, no waiting for a three year project delayed by three years to see if anything will work. This is like it starts working next week. Measurably. That’s very impressive. By the way it either works or it doesn’t. What you plug in might not have the effect you want. This is science, this is a scientific experiment, if it works, you keep it in the real system. If it doesn’t work, you dump it. Hypothesis failed. We’re using scientific method, to make agile happen. That is a sprint. And we repeat that process maybe 50 weeks in a row, maybe a hundred weeks in a row until all of our value goals are met. That’s the definition of done. So in other words, Thursday, we’ve gone agile.

What do we do on Friday? We take this crazy idea that they’ve never seen before of having top 10 on a page of requirements, top 10 of architecture done in a day. The impact estimation table shows credibility and this idea of what to do next week. We go to the top management make the presentation and suggest that we at least try a few weeks of this to see if we make any real progress. Management always says, yes, go do it for the very simple reason. They know they’re paying these guys, whether we do it or not, but now they have a chance to see if anybody knows what they’re talking about.

Murray: But how much is this gonna cost Tom? How much budget

Tom: First I’m gonna say how much budget do you feel that you have in terms of time to deadline and money to use. They’re gonna give you a framework of months to a year or so. They’re gonna give you fairly high sum of money. And what I do is I say fine you want it done by first or January? You have a million bucks on it. Fine. We will put that in as an architectural constraint. That it will be done by 1st of January. And it will not use more than a million bucks. We will then charge the architect to iteratively track the costs of time and money, and if necessary change the architecture. So it’s cheaper and faster on the fly. This was practiced magnificently by IBM clean room method iBM systems journal you’ll find references to this, and they always delivered military and space projects software on time, under budget, every time for 10 years in a row. So in other words, we don’t ask what will be the cost we ask, what costs of time and money would be okay for you guys. We will design it to have low costs and low time consumptions that’s engineering. That’s not coding. Now this is something not taught at all. People don’t even know that such an approach has existed and succeeded and well documented at places like IBM defense systems division. 

Murray: So then what I’m doing through the project is moving the needle as much as I can on the value metric within the time and budget available. 

Tom: Excellent summary, by the way, there’s something I didn’t say I’d like to plug in here. I talk about decomposition and prioritization here. When I I take this larger architecture I decompose it, but I decompose it into implementable chunks. In other words, things you can do in a sprint in reality, and I then prioritize by the chunks that give highest value for lowest cost, that alone tends to reduce the cost. You’re starting off, off with the low cost ideas. In other words, I control cost by many different devices. One is this prioritization by value to cost. The other is by rearchitecting, when you have a too high cost thing to a lower cost thing. 

Our engineers call this design to cost. And I call this in the agile mode, dynamic design to cost, cuz you potentially do it at every sprint. We’re adjusting the cost as we go along to be the cost in time and money that we want. The wrong approach is to try to make an estimate, what will it cost? And then multiply it times 3.14 and say, gee, we thought was gonna be a piece of cake. It turned out to be pie. 

Murray: Costs multiple times what you thought it was 

Tom: But that’s because we do not use or teach or know about dynamic design to cost as practiced by I IBM federal systems division for years successfully and well documented.

Murray: When I’m running this project, I’m not promising to deliver a whole series of features that I’ve estimated or components. What I’m saying is that I am going to move the needle as much as I can. And here’s what we think is a number of ways to do it. And we are going to try these things. We’re gonna see what works and what doesn’t, and we’re gonna focus on what moves the needle most, all the time. And, what’s the cheapest way of moving the needle as well.

Tom: You got it. 

Shane: Talking to lots of people on this podcast, it’s become very clear that there’s been a bunch of ways of working a bunch of principles, a bunch of practices, a bunch of patents that have been around for a long time. The number of people that come out of an XP background that have been doing it for many years before the agile manifesto turned up. And if I look at , the world of agile we have today, I can see a lot of the patterns and practices that were pre manifesto still survive. But the measurement one, unless you’re talking to somebody that’s doing more of a lean waste measurement, there’s still measurement in there that I can see, but in everything else, we seem to have lost the science of measuring where we’re at and measuring whether we’ve moved the dial or not. And also anecdotally, know, you hear a lot of. IBM people did this. IBM people did that. A lot of innovation seemed to come out of IBM, but it would probably be fair to say that IBM is not recognized as an agile leader in the world anymore. So why do you think that is? Why do you think we’d lost these practices? Why do you think IBM who seemed to have people who founded a lot of these lost the brand. What happened given that you’ve been there from the beginning.

Tom: This IBM federal systems division people led by Harland mills. I knew them and visited them almost on an annual basis to share secrets. They admired my software metrics book in 1976, for example. I knew them quite intimately. Now I’ll tell you why these methods were used internally at IBM. They were not sold in any way by any salesman at IBM, they were not selling software and software method at all. They were selling hardware and their operating systems and their compilers. As far as they’re concerned, it was a trade secret that they weren’t that interested that any competitor would learn about. They did, publish this stuff in IBM systems journal. You can, even to date via the university of Tennessee, get copies of what they published. Even though all IBM customers got a copy free copy of IBM system journal, they didn’t necessarily read it or understand it or appreciate it. So in other words the main reason IBM had very many good ideas that it didn’t become popular was that they didn’t try to spread it outside of. IBM. It died with the people who retired at IBM. Now that’s the reason some great things did not spread. Later IBM got in the business and what did they do? They bought up companies like Scott Ambler’s company and proffered the methods. At that point they were less interested in how good the methods were, but they were more interested in how well the methods sold. I think that’s one of our problems. That IBM and everybody else went into the business of selling the methods. 

Shane: There’s definitely a theory on our side about methods that are for sale. 

Murray: I want to know if Eva is so, good. Why isn’t everybody doing it?

Tom: Evo has never been marketed the way most of the other methods have been marketed. What’s happened with Evo is that companies like Intel, IBM Huett Packard, Boeing have come to me. After they’d read something I’d written or heard a conference speech, and I’ve worked with those companies for several years. Intel have 20 years of training over 20,000 engineers in my methods. And they’ve been using it for 20 years and they’ve not found anything better for 20 years by definition. Now, most people don’t even know that. And Intel, isn’t the least been interested in telling people and their competitors, what they’re doing.

In other words the way my method has been marketed, I haven’t tried to spread it to the world. I’ve written books on it and people who read the book or not read the book and people like Kent Beck and Jeff Southern have read my books and learned my ideas and made some use of them. Almost all the signers of the agile manifesto point directly to my book principles of software engineering management that had massive stuff about agile in it as a source of inspiration. So in one sense, my ideas of Evo have spread through the various agile disciplines. Kent Beck, Jeff Sutherland, and uncle Bob state, I am a source of many of their idea. On the one hand, my ideas have, I would say unsuccessfully spread via the agile manifesto gang. And have more successfully spread directly to my industrial clients, the big corporations who have done it seriously and done it property. All my really successful long term clients are engineering companies. They know they need engineering. They look at my methods, it’s engineering, it works on software and they use it. Now most of the people using variance of popular agile methods, they’re not engineering companies. They’re using it for it. They’re not using it for engineering. In a sense, they’re looking for a religion magic formula, a set of procedures to carry out to be agile. They’re not even seriously discussing success and the definition of success. Jeff Sutherland constantly complains that scrum fails 60% of the time cuz they don’t do scrum properly.

And I’d say that the ideas people have picked up from my methods have not been applied fully and properly they’ve just grabbed a little bit. The main idea they’ve grabbed is you could do it in small chunks or sprints. That doesn’t get you very far. If you add, and we should measure how much value we’ve delivered on each sprint, that’s completely missing. And that is the key idea. That’s always been there from the seventies in my work, the measure and get feedback and learn. It’s completely missing.

In other words, they picked up a 10th of the idea. Let’s call it the small sprint credit me. Oh my God. But successful projects done by the large corporation. And the department of defense is another, we have some very interesting examples of using my methods there.

They are. Pulled in by very successful companies. Now, why is a company large and successful for decades? And the answer is they pull in really good methods and they use them. They have a process for doing it. They send out their spies, find good ideas, bring them in, try them out. Companies like Huett Packard are famous for empowering their young engineers to try out anything without asking management permission and getting, approval from the saints of the method or anything like that. If it works, spread it, if it doesn’t dump it. 

Shane: So if we look at, the Intels, the HPS, Lockheed Martin and then we’ve got the fan companies, we’ve got meta, apple, we’ve got the Googles, we’ve got the Netflix. And if you look at those organizations, they work in an agile way, but they don’t, subscribe to an agile methodology from what I can tell, never work there. But just from the people I’ve listened, talked to. But I get the real sense that they’re measurement based, the Amazons of the world that they are

Tom: Yes. 

Shane: measuring a dial and watching the dial move. And if the dial doesn’t move straight out, if it does. So is that kind of what’s happened, is there again, they’re building ways of working internally, but because it’s to run their company and make them successful, they don’t really care whether they share it or not, because it’s not about sharing what they do. It’s about building a successful company. Is that pattern being repeated for those new wave corporates. 

Tom: I think you’re onto it by the way. I’ve just read my third book on Amazon and Bezos and he absolutely is fanatic on measurement. And he absolutely does things in small incremental steps. So I would say Jeff Bezos is a great agilist in practice. He isn’t always nice, but maybe you can’t be nice and successful . Musk is a Another AIST. I’m working on a book called Musks methods. Musk never wrote down his methods, but he talks about ’em and he transmits them by Twitter sometimes to his people. I got a flying start with an interview he did at his aerospace facility, his five major principles, by the way, principle number one, assume the requirements are wrong no matter who stated them and how intelligent or powerful he is. And he meant himself. Same thing applies to design. Assume it is wrong, no matter who stated it and how intelligent they are. This is the same as my plan analysis book. Musk is along with Bezos a great agilist in the best sense of the word. And he’s a great engineering agilist. He understands with a vengeance, quantification and engineering, but he also understands small steps of moving forward. So I think we ought to do is wipe out everything related to the agile manifesto and scrum and safe, and just say, look, here’s your agile course. Read the book on Musk’s methods now replicate. 

Murray: Look I really like what you’re talking about, but what concerns me about Musk and Amazon is the human side of things. They both have a long track record of being really awful to the people they work with. And agile has at its heart. A lot of things like empowerment, decentralization, self organizing teams, which is about human empowerment.

Tom: Now, number one. Let’s be careful. As I already hinted, both Bezos and Musk have had to be tough because if they weren’t tough, they would totally fail. The constraint is you’re gonna work your ass off and you’re gonna perform way beyond your own capacity. And hanging in there is really tough and not everybody can do it. Musk is only interested in the top caliber and capacity of people. And so normal mortals need not apply and, less than superior beings will have a tough time in that environment, but they do produce fantastic stuff, both economically and product wise and service wise. And there are an awful lot of people who hang in there decade after decade with Tesla and Amazon. it’s not like everybody’s leaving. I think these guys are worth study. I didn’t say we should all be them or be like them, but they are proving on a vast industrial scale that you can using agile methods and agile engineering. You can produce fantastic products and fantastic economics.

Murray: I think this might be a good time to go to summaries. Shane, what do you reckon? 

Shane: This Is an unusual one. So normally on the podcast we get recurring themes and a lot of what you’ve talked about, match up with those recurring things. So the idea of set a goal, let the team get on with it, but for some reason the way you articulate it, It’s different. So I like the idea that we talk about tech debt. We create a lovely spreadsheet of tech debt, and then we put it in the cupboard and we forget about it. We don’t talk about things that are measurable. We don’t talk about reduce the meantime to recover. We do agile theater, or we’ve got to get list. We’re good. We don’t fix it. 

I like the idea of asking the why, so again, that’s a common pattern. Why do we need to do that? I struggle with the word value requirements and that’s because it’s a term that means something else to me and has for a long time. So if I said setting the goals and how we’re gonna measure where we’re at, and whether those goals have been achieved, then I get that. I do like the idea, that you had about those goals can be set with different lenses. You can look at it from different perspectives and that will change what we are measuring. I thought that was really useful and that actually there could be a list of classes that we can apply against those goals, which give us that perspective and a set of measurements that we should look at. So I like that decomposition down into different ways of looking at it to make measurement easier.

So we should start off by measuring what we have and define what we need. It’s almost taking me back to the old BPM stuff. Which was time emotion studies let’s look at what’s happening and then let’s look at how we change something. So again we see a lot of repeatable patterns that we sometimes do better or well, and sometimes we don’t. I’m intrigued by the idea of build a scale of measure. Let’s get something we can agree. That’s the definition of a measurement. And then we can see where on the dial it is. So I like that. And I really like the idea that potentially there’s a set of scales. We can start with. And then we can tailor them or customize them to our context.

I like that. You can be taught to measure anything. Like I said, I struggle with it, it’s not a skill. I have to quantifiably understand what a measurement can look like and how to know where we’ve moved. It. I can do it sometimes, if I really put my mind to it, I can do it, but it doesn’t come naturally.

Tom: Read the Quanteer book to know how to do it. Always.

Shane: And then there’s a real skill to be able to do that repeatedly in a five day workshop with senior people, architects and get us through. I was really happy that when you talked about the process you use, it is a repeatable iterative process. It’s time boxed, it’s, prioritized. We get value out of it at the end of each iteration. I can almost imagine it’s on a big wall, and we can start at the goals and we can move through and we’ve almost got a storyboard or story map of those five days. So thank you for that. Murray. You got.

Murray: Yeah, , I have picked up the idea of putting a value on requirements about 10 years ago. And I have been talking for quite a long time to people about let’s deliver as much value as possible and budget available. We’ll do a ballpark. We’ll have two weeks we’ll come up with it, but then we’ll focus our contracts based on, fixed time, fixed budget for a team that is gonna focus on delivering as much value as possible on these metrics, but I’ve never really known how to develop a measure for things. And I’ve often found that we’re just guessing, we’re just saying what do you think? So I’m really pleased that I can go and have a look at your Quanteer book and dig into that. What I’ve been doing, superficially you’ve dug into really heavily, made a whole career out of it. And it’s very interesting. I think it’s a powerful approach And I think you’re right. It is probably what drives. Some of the best companies. So often companies take these value statements and just turn them into lists of requirements almost immediately. And you’re right. It’s, they’ve gone off and seen some products and done some research and made lists of requirements based on what’s been written in magazines or blog posts . And then they ask you for a quote for it and, blah, blah, blah. And it’s all, it all gets turned into these features and nobody really measures the return on investment or the success until three years and 10 million later. And then they go, ah, didn’t do anything. That’s probably what happens with most corporate projects. They don’t achieve any of the success goals that they set at the beginning because they lost interest in them after the first five minutes. 

Shane: Unless the success criteria is somebody’s earned 10 million. If that’s our success criteria, all those projects are highly successful.

Murray: The current way of working is great for Accenture and Deloitte companies trying to make consulting revenue. So it’s really important to focus on measuring what’s valuable and I’m gonna have to look into this more

Tom: Could, I make a subtle point? I make a big distinction between quantification putting a number on it and measurement. So quantification is a way of modeling and thinking about a problem. Measurement is a way of getting feedback on your delivery cycles. They’re related, but they’re not identical.

So what, there’s a lot of people when I talk about quantification because I’m interested in making things 

clear, automatically assume that it’s all about measurement. And I say measurement, isn’t the main point at that point, clarity of purpose is the main point And you don’t need measurement to have clear language, but you need quantification to clarify critical variables.

Murray: All right. So you’re gonna give us a list of books that we can share. Do you have a website or a blog that, people can go and have a look at? 

Tom: My website Guild.com gives a lot of stuff. Then the blog is really my LinkedIn and Twitter, which are almost identical. So every time I have a new paper or talk for example, like this one, I tend to put it on LinkedIn with copy to Twitter. So that’s the way of following what I do. I almost never advertise anything for payment, but I try to only advertise what I will give away free. 

Murray: What you need is a commercialization model with a certification program, $2,000, two days certified success engineer. I think we’ll call it and I’ll be the success engineering trainer and I’ll make yeah.. Engineer bit Shane.

Shane: I’ll do you a big, a three diagram with lots of boxes and lines and we can put people in the right box. Right. 

Tom: Okay. We all get rich together. 

Shane: that content with we really appreciate. 

Tom: I’ve actually written a book called success. And I’m sending it to you right now with permission to share it. Now I’ll tell you what I wrote the book. I have some agile friends who are well known and in high places who will remain anonymous, who are like you and I very frustrated with the current state of things in agile. And I finally said, look, let’s stop fighting the windmills of agile. Let’s ask a very simple question. Why does anybody do any form of agile? And the answer is they wanna succeed in something. Let’s go to a higher level. The success level. Let’s focus on defining success and architecting for success and incrementally delivering success. And let’s say that anything that delivers that success is good and anything that doesn’t deliver that success is bad. And in other words, let’s just go to a higher level of thinking instead of religious practices, which are supposed to give you success. Why not define success for you architect for success and measure that you are incrementally and early getting success. Anyway, written a whole book about it. I offer it for free to your listeners . 

Murray: That’s generous of you. 

Tom: I’m as generous as a heroin dealer. I give free samples hoping you’ll get addicted to the ideas.

Murray: That’s a good one. I like that. Hey thanks very much for coming on, Tom. We’re enjoyed talking to you. 

Tom: Thanks for listening and thinking about it. And, your feedback is encouraging. Feel free to contact me about any of this stuff. If you just wanna talk about it now, I’m, I’m retired. So you know what? My, my only mission in life is to spread these ideas, not to self them.

Murray: All right. That’s been great. Thank you. 

Exit: That was the no nonsense agile podcast from Murray Robinson and Shane Gibson. If you’d like help with agile contact Murray evolve, that’s evolve with zero. Thanks for listening.