BONUS Tom Gilb: Building True Engineering Culture and Delivering Value Through Evolutionary Methods

Summary

Scrum Master Toolbox Podcast: Agile Storytelling from the Trenches
Episode: BONUS Tom Gilb: Building True Engineering Culture and Delivering Value Through Evolutionary Methods
Host: Vasco Duarte
Release Date: May 27, 2025

---

Introduction

In this special bonus episode of the Scrum Master Toolbox Podcast, host Vasco Duarte engages in an enlightening conversation with Tom Gilb, a pioneering figure in the Agile movement. Gilb, an independent teacher, consultant, and prolific writer, delves deep into building a true engineering culture and delivering value through his evolutionary (EVO) methods.

Guest Background

Vasco introduces Tom Gilb as a veteran of Agile methodologies, noting his early contributions to the field even before the term "Agile" was coined. Gilb's seminal work includes the introduction of the term "evolutionary" in his 1976 book, Software Metrics. Over the decades, he has authored numerous books, with an impressive tally of ten published in the past year alone. Despite his semi-retired status, Gilb continues to influence the Agile community through his writings and consultations.

Defining Success in Projects

Tom Gilb emphasizes the importance of defining what success means in the context of project management. He critiques the prevalent focus on Agile practices themselves—like stand-up meetings and certifications—arguing that these do not inherently ensure project success. Instead, Gilb posits that success should be measured by the achievement of clear, multi-dimensional goals that deliver tangible value within budget and time constraints.

"Who cares if you're agile or not if your project is failing." – Tom Gilb [03:13]

Measuring Value and Multi-dimensional Objectives

Gilb introduces the concept of Quantified Multidimensional Objectives, which involves setting clear, measurable goals across various dimensions such as security, usability, and reliability—not just financial metrics. He argues that without quantifying these critical qualities, organizations cannot effectively assess or deliver value.

"Value can be profit and sales and market share. But for many stakeholders, like the user, it's the usability, it's the security." – Tom Gilb [05:38]

Critique of Current Agile Practices

The conversation highlights a significant gap in the current Agile practices: the lack of engineering discipline. Gilb criticizes the assumption that design and architecture can "magically emerge" within Agile frameworks like Scrum. He contends that without deliberate engineering and architectural planning, especially in large and complex projects, Agile methodologies are likely to fail.

"People don't get demanding state of the art qualities by accident. They have to fight hard and have knowledgeable designers and architects to get there." – Tom Gilb [08:23]

The EVO Method: Stakeholder Analysis and Requirements

Central to Gilb's approach is the EVO Method, which begins with a comprehensive stakeholder analysis. Unlike the conventional narrow view of stakeholders (e.g., only bosses or direct customers), Gilb expands this to include laws, regulations, contracts, and other non-human entities that impact project requirements.

"Stakeholders hold a stake. That means they have a requirement whether we like it or not, whether we know it or not." – Tom Gilb [21:25]

He underscores the necessity of quantifying stakeholder requirements to align project outcomes with actual value delivery, moving beyond vague promises to precise, measurable targets.

Design and Decomposition

After establishing stakeholder requirements, Gilb discusses the importance of robust design and the process of Decomposition. He advocates for breaking down large design goals into smaller, manageable increments that deliver immediate value. This approach not only facilitates early value delivery but also promotes continuous learning and adaptation.

"Can I deliver this design to my existing system to make it better no matter how bad the old existing system is? Can I do this next week?" – Tom Gilb [28:56]

Prioritization and Impact Estimation

Gilb introduces the concept of Prioritization through an Impact Estimation Table, which helps teams determine which tasks to tackle first based on their value-to-cost ratio. This method ensures that the most efficient designs—those offering the highest value at the lowest cost—are implemented first.

"The most important thing about that cycle is not merely that value is delivered early, frequently and measurably, it is that you learn early." – Tom Gilb [26:56]

Learning and Continuous Improvement

A critical aspect of Gilb's methodology is the emphasis on learning from each increment. By measuring the actual value delivered against expectations, teams can identify discrepancies and refine their approaches in real-time, fostering a culture of continuous improvement.

"The best competitors will be the ones that learn the fastest through this cycle." – Tom Gilb [36:48]

Integrating Lean Startup Principles

Gilb's EVO cycle mirrors the Build-Measure-Learn feedback loop advocated by Lean Startup. This alignment underscores the universality of iterative learning and value-driven development across different Agile frameworks.

"Tom, I really love how you built also the Lean Startup cycle into your EVO cycle. Because of course build, measure, learn is exactly the cycle that Lean Startup argues for." – Vasco Duarte [37:27]

Resources and Further Reading

Tom Gilb recommends his recent EVO book as a foundational resource, which includes extensive references and links to additional Agile literature. He also encourages listeners to explore his free materials available on platforms like LinkedIn and his personal website, tomgilb.com, for deeper insights.

Conclusion

The episode wraps up with Gilb sharing his enthusiasm for spreading his engineering-focused Agile methodologies. He highlights the importance of both technical and management leaders embracing engineering disciplines to ensure project success. Vasco reinforces the value of Gilb's insights, encouraging listeners to integrate these principles to build a true engineering culture within their organizations.

---

Key Takeaways:

1. Define Success Clearly: Success should be measured by achieving multi-dimensional, quantifiable goals that deliver real value.
2. Embrace Engineering Discipline: Robust design and architecture are essential, especially for large and complex projects.
3. Stakeholder-Centric Approach: Comprehensive stakeholder analysis ensures that all requirements, including non-human ones, are addressed.
4. Iterative Value Delivery: Breaking down projects into small, value-delivering increments fosters early success and continuous learning.
5. Prioritize Effectively: Use impact estimation to focus on the highest value tasks first.
6. Continuous Learning: Measure and learn from each increment to refine processes and improve outcomes.
7. Leverage AI and Modern Tools: Utilize AI for tasks like stakeholder analysis and decomposition to enhance efficiency and accuracy.

For those interested in delving deeper into Tom Gilb's methodologies, his EVO book and accompanying resources provide extensive guidance and practical examples.

Transcript

[Vasko]

Hey there, agile adventurer, just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast. Hello everybody. Welcome to a very special bonus episode. And today we have with us someone I've been reading and following for many, many years and his name is Tom Gilb. Hey Tom, welcome to the show.

[Tom Gilb]

Thank you.

[Vasko]

It's a pleasure to have Tom on the show. Tom is, I would say an old timer of Agile, but he's. He was talking about agile before Agile was even named. He wrote about, I think it was 76, Tom, that you introduced the word evolutionary. Okay, so I was one year old when you introduced the word evolutionary. Wow. So that was in his book called Software Metrics. If you know Tom, you know he has many books available. He was at the time advocating for development in small measurable steps, which today he calls Evo, the name that he uses to describe his approach and is an independent teacher, consultant and writer these days. He's retired, or at least he told me so. But he keeps on writing more and more books, right?

[Tom Gilb]

Yep, 10 last year.

[Vasko]

Wow. And today we're going to talk about one of those books. We'll be talking about a book titled. And you're going to love this for sure. The title of the book is Success Super Secrets and Strategies for Efficient Value Delivery in Projects and Programs and Plans. Is that a reference to your plan?

[Tom Gilb]

Not intentionally.

[Vasko]

Check out the book on Lean Pop. The link is in the show notes. But Tom, before we dive into what you wrote in the book and all of those lessons and value bumps that you dropped in that book, why did you even start writing that book in the first place?

[Tom Gilb]

Because people were doing things, for example, agile, and they kept on describing what they're doing as, you know, doing agile or being agile. And I thought, who cares if you're agile or not if your project is failing? And a great many of the projects were failing. And so I said, well, what does it mean to fail and succeed? And to succeed is to reach the goals you set, even though they might not be perfect goals, you know, but you have succeeded in what you tried to do. And there was very about setting clear goals and reaching them. People didn't discuss that. They discussed their stand up meeting or what should people with certain certificates do in a group. And that had nothing to do with whether they were successful or if there was a correlation. People didn't talk about the correlation between the agile practices and actual success in meeting improvements for an organization at lower cost. And in very simple terms, that's my definition of success. Some improvements you want at costs you can afford.

[Vasko]

That sounds like a tagline for a podcast teaching people how to, how to organize successful software delivery.

[Tom Gilb]

Right, that's what we're going to do part of now and we can do more as needed.

[Vasko]

Absolutely. So let's get started and jump into those super secret and successful strategies at efficient value delivery. I really like the fact that you've been talking about, I mean, you started talking about value before value was cool, right? Like we were in the good old days of rational unified process being the cutting edge of software processes. Of course we look at that right now and find it a bit quaint, maybe even a little bit too waterfallish. But more on that later. So early in your books you started talking about defining success through and you wrote quantified multidimensional objectives. What were you trying to expose with that reference? I mean, isn't already everybody doing that with, for example, OKRs?

[Tom Gilb]

Well, OKRs came much later and OKRs do represent a quantification of success, no problem. I have written a paper called what's wrong with okr? In other words, I think it's better than not defining these at all. But I think it has, let's say, 10 weaknesses that need to be explored and dealt with. It could be better, but that's another matter. Remember my 1976 book Software Metrics, that had very many practical examples of how to quantify values like security, usability, availability, all the ilities, all the qualities. So, you know, from that moment, you know, for me, you had to quantify the critical qualities of a system in order to talk about value at all. You know, of course, the word value, as everybody knows, the first thing you think of is mon Monetary value, financial value, profit. And so some people, when they talk about value, they mean profit. You know, they don't mean any, let's call it, it value like security, usability or something like that. So one thing I've always tried to do is to say, well, value can be profit and sales and, and market share. But it, it for many stakeholders like the user, it's not the profit, it's the usability, it's the security. Right. So, yeah, so number one, to even begin to talk about being successful or having good methods of any kind, you have to have a definition of what it means to succeed. And that definition has to be multi dimensional. There's no one dimension like profit. Right. And there's no one dimension like reliability of the software either. There are always multiple dimensions simultaneously, at least 10 critical ones, not one or two or three. Right. And if you don't clarify exactly what they are, they will never happen. You can't.

[Vasko]

Except by accident, of course.

[Tom Gilb]

Yeah, by, well, they won't even happen by accident, not in your lifetime. Yeah, yeah. So you, you, you've got to. And people just haven't learned to quantify much more than profit and sales.

[Vasko]

One would argue that they might not even quantify that.

[Tom Gilb]

Yes, right, that's right. That could be tricky too. But in particular it, people who know that they have a lot of qualities like usability, security, they haven't learned to quantify those things. They wave their arms and say, yeah, we definitely need higher security because we got hacked last week, but it's all nice sounding words. But when you've done with your five year project for five billion quid, you cannot prove that you achieved anything because you didn't say what you wanted to achieve. So you could say what we achieved is what we intended, therefore we are successful. It's like painting the target after you've shot the arrow.

[Vasko]

That's a very good point because one of the things that I always rally up against and very often get pushback and on is this idea that you can develop software based on a list of tasks. And of course you can, literally you can do that, but that has no bearing to what the software should deliver for the business, the users or any of the other stakeholders. Because the tasks that we do in software are not necessarily related to the outcomes, the impacts, the value that we want to achieve.

[Tom Gilb]

That's right. Now there's a word hiding implicitly in what you said and I want to bring it out. It's another one of these elephants in the room that people constantly avoid Learning about and doing is called design. You don't get high security of a system without designing it and in larger systems without architecting it. Higher level of design. Right. And design means finding the technologies that give you that high level of security. Right. So you have to know how high a level of security you want. And there's tremendous variation in what people need. Okay. Tremendously different types of security. So you might say there are at least 10 interesting dimensions of security. And then depending on whether you are, you know, flight control or invoicing, you will probably need different levels. Levels, you know, degrees of security. So this requires. Now there's another word hiding. There's. I mentioned design and architecture and we need to learn. People do not learn in things like Scrum for example, to design or to architect at all. In fact, the design magically emerges. Ridiculous. Something bad emerges, that's for sure. And if you call that design, that's it. But people don't get demanding state of the art qualities by accident. They, they you have to fight hard and have knowledgeable designers and architects to get there. Now there's something hiding behind the idea of design. And if I say the word engineering and for example, many Years ago, maybe 78 I published data engineering. That and always been into systems and software engineering. And I mean real engineering, not programming. I'm a software engineer. That actually means I'm good at coding, nothing to do with engineering. We've been flying a false flag for far too long there. But real engineering is now not necessary for trivial systems. You can hack and code together. You know, a craft, a good craft person, soft crafter I call them in my 1988 book Principles of Software Engineering Management Engineering management. Right now the. So you know, real engineers know what engineering is it people and managers don't. They seem to have no concept whatsoever.

[Vasko]

You know, they. And that's actually something I want to explore a little bit more. You've just said it. That, that and you raised that in the success book as well. The observed lack of, of engineering discipline in engineering or at least in name engineering organizations. And beyond the observation which you just related. Why do you think that is? Like why are we in a position where people who should be at least some of them trained engineers are not acting like one.

[Tom Gilb]

I think we can begin with even higher level question which ends up answering this one. Okay. Why is the failure rate of our projects so high? Okay, now depending on what domain you look at and what surveys you look at the failure rate, let's define failure runs way over budget, runs way over time, you know, deadline or does not deliver the benefits promised. Okay, so that now there's a guy called Bent Fluviberg who wrote a book called How Big things Get Done. Highly recommended. He has a database in Oxford where He's professor of 16,000 projects. Not all of them are it. There are buildings and everything else. But he has an interesting statistic. Something like half of all of his projects fail to deliver on time and or fail to deliver within budget significantly. And 99.5% fail at least one of the three criteria. Budget, deadline, benefits. Now, when I talk about success, I'm talking mainly about the benefits. Delivering the benefits promised for the project. You didn't get your budget for nothing. You got it because you promised benefits at some level. Now he says 99.5% failed at at least one of those three criteria. And some of them, many of them all. Now that means we have a 0.5% project success on all three criteria on time, within budget and delivered benefits. Okay? Now we have similar things like strategic planning. I've been studying that a lot recently. And they say that strategic plans at top management level between 90 and 98% failure rate. Okay. Now as you know, there are many published studies of IT projects and it's similarly bad. You know, this is way above 50%.

[Vasko]

In fact, I just published an article recently where I recounted five different government led IT projects where the failure rates they are not all government, but there were three government, two private. The failure rates. Oh, sorry. The over budget amounts in those projects were ungodly. And in one case, in Kmart's case, Kmart declared bankruptcy with a loss of about 200 million at the same time as executing an IT project of 1.4 billion with a B. So clearly it destroyed the company. That is not to say that there are other side of the business was working that well. But if you think about it, 200 loss declared bankruptcy. 200 million loss declared bankruptcy to 1.4 billion investment in an IT system. You can clearly see where the problem was, right?

[Tom Gilb]

So now by the way, this problem has been there all the time. You know, for the history of it. In the beginning nobody cared much. You know, just get the damn thing working and well, sorry, went over budget, but we can afford it, you know. Okay, now, okay, so we acknowledge ridiculously high failure rate. Failure rate of 1%. Okay. It can happen to anybody. But when you get up in the 90s, you clearly have totally dysfunctional culture. Now what has society always done when projects become large and complex like pyramids and they Use architecture and engineering as a discipline to deal with the size and complexity. In other words, you don't need it for trivial projects. You know, I'm going to hack together this program in a week. Me. No, you don't need any engineering. You need craft, good craft. A problem is so much of our IT culture is really a craft culture. I love coding and programming. All the Agile Manifesto guys to this day, like, can't back declare, I love coding, I want to code. You know, they're coders at heart. That's fine and I hope they're very good coders. And the world needs good craftspeople to build pyramids, pull the blocks up there and put them into place and chip them to the right size. But pyramids didn't get built by people who are good at chipping away at stone. There were clearly architects and clearly high class engineering. Okay, so this is always now what's happened is we had simple beginnings, you know, I mean, I, I would write pro programs alone for my projects in, in days in COBOL or something like that. Okay, the old days. But as, as things get larger and you're, you're dealing with the worldwide air traffic control system or something like that, you're at a level where engineering and architecture is necessary, whatever that is now. And if you don't use it, you will fail. Right now the people doing this, the IT people and the managers are not trained. They don't even know a definition of engineering, let alone what it is. No clue. And they don't want to know. And they avoided it. Okay? The coders just want to code and the managers just want to say pithy phrases of we're going to defeat the competitor in the long term or strategy bullshit. So they're not exposed to engineering culture. By the way, I've worked for a lot of companies like Intel, Hewlett Packard, Ericsson, et cetera. Now these companies are founded by engineers and they're staffed by engineers. And these were my clients. They knew immediately that I had some engineering stuff and they needed the engineering stuff for systems and for software and they deployed my methods widely. But the say civil service people programming in cobol, large projects in Britain or something like that, they had no idea what engineering.

[Vasko]

Okay, But I think we've flogged a dead horse here. So moving on from the lack of engineering, we need to make this practical. You make that practical in your own writing. Like one of the aspects that you bring. And it's in this book, the Success book, it's the EVO method. And you actually apply that at different levels, or you call them fractals. So it's kind of deeper level of detail as we go into the execution of the EVO method. So let's talk about the critical aspect, the starting point of that EVO method, because the EVO method is, as you describe it, an engineering method. But it starts with some. Something very concrete that is relevant for this success book, which is the idea of a stakeholder. Right. And for most organizations today, and probably most of our listeners, stakeholder is probably restricted to their boss or maybe a fuzzy customer out there. Right. But your perspective on what stakeholder is is quite different. Can you share with us within the context of dievo method, how do you define the word stakeholder and why is that important for your engineering approach to deliver systems?

[Tom Gilb]

Got it. Okay, now first, stakeholders hold a stake. That means they have a requirement whether we like it or not, whether we know it or not. Okay. Now stakeholders are also not only people and groups of people, they're also non biological things like European law, GDPR and contracts and policies and plans. They have requirements for us. And these are quite important as people like Google and Apple who just got sued for hundreds of millions of euros by the European Union, they did not, obviously did not foresee that they had to respect the stakeholder called the European Union. Okay, so, okay, so, so, and we don't. This is not a discipline people learn. You know, they are extremely. You, you missed one word there. One trade. I know you know it very well. User, user, user this and user that. Fine. One stakeholder amongst 20 or 30 or even more.

[Vasko]

Yeah, yeah, but, but you talked about this discipline and this is really important because when you talk about stakeholders, you're not talking about abstract things, although law could be, if we're talking about it in general as an abstract. But you're actually making it much more specific in your methods. Can you talk to us about that?

[Tom Gilb]

Okay. I believe that you need to start your projects by analyzing your stakeholders. Your business analyst function needs to say, who are my stakeholders? By the way, if you find this intellectually difficult, which you shouldn't if you're a business analyst, but you might, if you ask your favorite AI system, tell me why 40 top critical stakeholders, it will immediately give you a very good list. If you simultaneously ask your AI system, would you mind listing the three most critical values for each of the 40 stakeholders, it will do so better than any human being you've ever met, including me. It just has a broader understanding of the stakeholders and what they require. If you in the same breath. And I've done this many times and I've published it in my later books, like the ones last year. Say, by the way, would you mind quantifying and suggesting a goal for us for these values for the stakeholders? It will do it better than any human being I've ever trained or not.

[Vasko]

And you can even ask it to write it in a language.

[Tom Gilb]

Yes, my planning language, Language. And you can do this all in one breath. And this is in. If we pick, oh, for example, if we pick the EVO book, which I think we're going to want to share with people, then you will find examples of doing this with AI with the prompts. Okay. So it's always been a difficulty training people. Like they couldn't believe there were so many stakeholders and they couldn't believe there were so many values, and they couldn't believe you could quantify all the values. But you know, AI is already has a superior intelligence to you right now, and it will take your job right now if you don't pretend that you did it instead of them.

[Vasko]

So one of the things that for me is really interesting is that this idea of choosing your stakeholders, figuring out what are the values that they want, and then quantifying that as input to the development process is actually the beginning of that discipline of engineering that you talk about.

[Tom Gilb]

Exactly. It is the beginning. And then once you've got the values quantified, you're in a position to say, design something, meaning find some technology or ideas of any kind that will get me to the levels within my budget and within my deadline. It's always, you know, the, the, the values within constraints of various kinds of budget and deadline being two primary constraints. But there are other constraints. Like following European law is a clear constraint.

[Vasko]

Absolutely. Although I wouldn't trust AI to know all of the requirements that we might need to follow. It's a great starting point, especially if you can then for example, double check that with legal or with your a very experienced programmer or architect or whatever it is. But for me, really, I think this is my opinion, having read the parts of the book, not the whole book, but when you talk about the GILP cycle of success, which is really evo applied to this idea of how do we design for success when running software projects, you emphasize these small measured value delivering increments and this stakeholder mapping, stakeholder requirement elicitation and then quantification of those requirements is really the beginning of that cycle that eventually leads to this EVO method. Right.

[Tom Gilb]

Okay, so I'll Take the next step after design, because I haven't gotten there, but you're hinting at it. So if a design, typically you will have a number of designs. There's not one design. It's always a set of, you know, this. I often even just talk about the top 10 most critical designs initially and the rest later. But so let's say we take the, the one design that is gives the best effectiveness, in other words, values at the lowest costs that I call the most efficient design. And we take a look at it and we ask a simple question. Can I deliver this design to my existing system to make it better no matter how bad the old existing system is? I believe very strongly you have to attack the existing system to get things going quickly, not wait five years until the new system is built. That's ridiculous. Okay, now the. But if you take a look at it, you ask a simple question. Can I do this next week? Because I'm fanatic in my evo on getting stuff done next week and every week until it's all done. And I know it can be done, but I know people don't know how to do it and they're in denial and it can't be done anyway. You take this great design idea and say, no, no, it's going to take three months. Okay? I said, well, that's 12 times too big for me. So now we have a phase called decomposition, which is taking that design and this is engineering and decomposing it into 12 weekly efforts. Each effort will give you a little bit more value. Okay, now people are typically in denial. This cannot be decomposed. I heard it my whole career.

[Vasko]

Yeah, me too.

[Tom Gilb]

Give me five minutes and I'll do it. And you will admit you were wrong and I was right.

[Vasko]

And then, yeah, even the thing that really surprised me is that even people who are agile proponents, maybe even agile advocates, say sometimes, oh, this cannot be decomposed. And I'm like, look, we ultimately need to decompose this to a single key press. We can certainly decompose this into one week chunks, Right?

[Tom Gilb]

Well put. Yeah. So now another thing I found is that if you instruct your favorite AI system to decompose it now there are two, two outcomes. If you just simply say decompose it, it will decompose it into a series of 12 tasks, will deliver any value, say, no, no, no, no, no, no.

[Vasko]

We don't want that.

[Tom Gilb]

Yeah, I've had to teach humans this for years too. No, no. Decompose so that each increment gives you some Value. And it will do that very well, putting the deniers to shame. You know, it gives you. They will even tell you you're going to get 5% of your expectation on the first one and 10 on the next and you can instruct it to do that. And this is in my books now. Okay, so yeah, now what you. Now what you have now. Now we're doing Agile as it should be.

[Vasko]

Agile as it should be. Well put.

[Tom Gilb]

I described it in my 1976 book, page 214. Okay. Which I have republished in some.

[Vasko]

And by the way, I think it was you who mentioned that a lot of what we call agile today was already being done. I believe in HB in the 7th as well. I don't know if it was you who mentioned or somebody else, but I do remember so, meaning that these ideas that were at some point labeled as agile, they were already emerging in the software industry. We just didn't have enough critical mass because something else was taking the attention.

[Tom Gilb]

All the old programmers saying, well, I was always doing that code a little bit and see what happens. Nothing new.

[Vasko]

That's what I always did. Command line testing, everything I did.

[Tom Gilb]

So they just, they didn't have a name for it, it was just programming for them. Right. But it was saying, I did my First Agile Project, 1960. I was 20 years old. I had an invoicing system using some IBM machines and I delivered it in 20 deliveries, each one of which gave value to my customer. And when I had delivered and I had the value locked in, I did the next step. I did that intuitively do a little make sure it works, build on it. That's all. I was 20 years old.

[Vasko]

And the thing that is really cool is that even though it was, as you said, mostly craftspeople who kind of developed, implemented, also implemented the necessary tools we need in order to do Agile in the software development. The fact is that in order for that to really work well, we do need this engineering thinking piece that you were talking about, which, which starts all the way from the stakeholders and the quantification of their, you call them requirements, I might call them needs, desires, hopes, goals. But those are the things, right? So one of the things that I need to ask, of course, I mean, you have a lot of experience with this, you've helped many people do this. What can we do to help leaders within the software development industry to start taking these steps to building a real engineering culture?

[Tom Gilb]

Okay, now there are two leaders. There are the technical leaders and there are the management leaders. Okay, now to the management leaders I would say, why don't you just demand a value stream of results from next week? And they say it can't be done, too difficult, we don't know how to do it. Said, well, I believe Tom Gill that you can do it and it's in his damn books. So you read the books and if you can't do that, I'll get my AI system to do it for me and you don't need to come to work. That's what I'd say to the and you know, these guys would love to have results early rather than failures late and lose their job. Okay? But they have to, they haven't even understood it is possible to demand it. And their technical people have pushed back out of ignorance. They don't know how to do it. It. Okay, now to the technical people, I would say, well, learn the engineering process. Learn what stakeholders are, learn what design is. That's your CTO technical responsibility. You know, learn engineering. And if, if you can't figure it out, just, you know, you're home in the evening, ask the AI system how to do it and it will tell you it's very good at it. You know, there's no lack of knowledge here. You don't need me to be there. Okay? By the way, I want to complete the cycle and make a summary before we get a point where I don't have time to do it. Okay, so after the decomposition, let's say you've decomposed into 12 weekly steps, right? There's another engineering process. I call it prioritization. Which one of the 12am I going to do? They should ideally be independent and I could do any one of them. And the simple answer is the one that gives the most benefit for the least cost. Now, to do that, you have to estimate the benefit numerically and estimate the cost numerically. Now you have the data to say which one is the most efficient. Let's do that first. That's engineering. Now what does that mean? It means that in the first 20% of your project, you will deliver 80% of the value. That's nice. Not the value at the end that we promised that never arrives, but the value arrives early and is very visible. That's how it should be and never is with our Scrum type, you know, Agile Manifesto type thinking now, okay? And I use a thing called an impact estimation table to estimate the values and the costs and to automatically make the decision, the engineering decision. Which one of these should I do first? Now, very quickly, you then build the design, you implement it into Your existing system, you measure whether you got the value or not and you learn. This is the stand up meeting in engineering style. You learn from the numbers. Damn, we thought we were going to get 10% of the value. We only got three. But we got three. What's wrong with our thinking now? The most important thing about that cycle is not merely that value is delivered early, frequently and measurably, which is fantastic. It is that you learn early. Okay. And the most important thing about that cycle, you see the people who will be the best competitors. Now I'm talking to the CEO and the Chief Marketing officer. The best competitors will be the ones that learn the fastest through this cycle. That's the high level view is forcing the IT people to learn what works and what doesn't work for real. Not after a five year failed project where they go on to which was.

[Vasko]

Estimated to last six months. I've been in some of those.

[Tom Gilb]

Right. Force the IT people to learn from reality.

[Vasko]

Tom, I really love how you built also the Lean Startup cycle into your EVO cycle. Because of course build, measure, learn is exactly the cycle that Lean Startup argues for. Okay, we'll put the link to the success book on the show notes, but what do you think is one critical companion resource for our listeners to read or listen or watch if they are interested in exploring more this idea?

[Tom Gilb]

Okay, I think I mentioned the EVO book which I wrote last year. Now by the way, I have a whole series about agile including but the beauty is the EVO book has a list of references about four to six pages and there is a vast quantity of agile literature like Agile Design and it's free downloads and the links are in the references of the EVO book. So by giving the EVO book we give the primary this is how agile should be done in excruciating detail everything we talked about here. But it also gives anybody who wants access to the more specialized like the Agile Design book, things like that.

[Vasko]

Absolutely. We'll put the link to the show notes and if people want to contact you and know more about what you're doing these days, maybe what books you're writing these days, where can they go?

[Tom Gilb]

Well, of course LinkedIn and X. So every time I write something new I put it up on both LinkedIn and X number two and it's always free stuff. I'm never advertising or selling my books these days. I, I just want to spread the good news, the, the gospel. And in, in addition, people are very welcome to contact me tomilb.com if they want to go deeper than the books, you know, allow them to do. I'm retired. I've got nothing to do except to talk with interested people about interesting things. That's my hobby. In retirement. You've got to have a hobby or the wife will have you looking at baking programs on tv.

[Vasko]

I'm definitely for the hobby, but I do love those baking programs though.

[Tom Gilb]

I have to look at them sometimes, but I look at my Mac at the same time.

[Vasko]

Very good, Tom. It's been a pleasure. Thank you very much for your generosity with your time and your knowledge.

[Tom Gilb]

Thank you. One little detail you asked about earlier practice of Agile. Now remind me. There's a chapter 15 of my principles of Software Engineering Management book which is all about the early evolutionary practices and I have a PDF of it and we can share that so you can see the very wide practice. This is before 1988. Remind me, I'll send it today.

[Vasko]

Absolutely. We'll put the link on the show Notes Tom thank you.

[Tom Gilb]

Thank you.

[Vasko]

All right, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you. The members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep dive interviews, books, and if you're into no estimates, we got the pioneers of no estimates in those deep dive interviews as well. Agile Business intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners. Plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community community that's shaping the future of Agile. And we have so much for you. So check out all the [e-mail] membership because listening is great. It's important. But doing it together, that's next level. I'll see you in the community. Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.