 Alright, thanks folks for joining in. Tom, this conference, you know, I happened to start this back in 2004. We've been running this. And so over the years, you would see that, you know, there are quite a few people that have been part of this community helped us build this. And, you know, that's where you see a lot of these familiar names folks who kind of come back. And I'm sure everyone has been waiting for this opportunity to meet you, unfortunately, not in person but, you know, virtually at least. It's such an honor and it's such a privilege Tom to finally have you, you know, talk to talk to the agile India community. Tom is someone that again, most of us have been deeply influenced by Tom's work. I remember, you know, back in like many years ago someone gave me your software metrics book because that was one of the area that I was pretty keen on in terms of measuring, you know, what we are doing and when we're trying to go there we go. Absolutely. And this has been such a such an instrumental book, Tom, in a lot of work that we do in fact, even just a few months ago there's a bit of an open source project that I built where we try and, you know, measure some of these metrics in there from the book as well. And I was referring to like this, this work is, is before I was born, this work was that before I was born, which is pretty cool right so. And I think you can also talk about some of your work with with the Indian government and data and your role you played in CMM for. So, you know, again, I think it's just a great honor to have you Tom and looking forward to to your talk. And without much delay I'm going to hand it over to Tom. Right. So here is our title agile engineering. So I'm going to try to put the engineering in agile, because it's not there yet. And we don't need engineering for very simple small projects, but we need engineering for the large complex ones that are facing almost everybody. I have about 37 slides. I'm going to go as obviously a pace of about one slide a minute. And many of my slides have a lot of detail in them. And you will not have time and I will not have time to go through the slides in detail. So I will present a highlight and if it interests you, you can go back and get a copy of the slides and study them later and you will find very many free books and papers to allow you to go into more depth in the projects that interest you. I have a photo of me with the early books from 76 and 88. And they both contain considerable agile information. I'll give you a sample in a moment. But the, we didn't call it agile for many quarter of a century we called it evolutionary delivery, even the US Department of Defense called it that it had special standards for it. So but agile is the popular term that my friends agreed on. If you want a copy of the slides you'll find them at the conference site you'll also find them here. And if you want my what I call my agile library. This is a collection of very many things I've written papers and talks mostly, but videos on agile, you can use this qr to get a hold of it. So, I couldn't resist putting this picture in. Sorry, one picture too many. I think. Okay. Well, there's a picture of me at my son Kai, who lectured at agile India recently, his wedding at Shri Shri Ravish tankars ashram in Bangalore, and my wife and I, and my older son are also in the Indian costume. Shortly after the wedding I went to an IT conference in Bangalore, and everybody had to have a picture with me because I saw tall. And they said, Tom, you look like Indian Prince. So I consider myself an amateur Indian Prince. Here's the agenda about 16 subjects, about 45 minutes. And we, and then there's also the link to the agile library there. Okay, so I would like to quote to you from the book where metrics book the US edition came out in 77. And from page 214, and I'm quite proud of what was there, because I think it not only defines agile, but it defines agile as it should be, and is not. That is, there is some engineering here, a complex system, which is what we're interested in for engineering will be most successful if it is implemented in small steps. No surprise. That's the basic idea that everybody agrees to with agile small steps. And if each step has a clear measure. Metrics measurement software metrics book engineering, a clear measure of successful achievement. For example, if we're trying our project is trying to enhance the security of the system, we should be measuring security increases at every sprint. Got it. Do you do things like that. As well as a retreat possibility to a previous successful step upon failure. So a step can fail, but we need to be able to retreat and go back. So, this is also my recipe for always being successful and never failing on a large scale. So, yeah, so my first point is there is far too much emphasis on coding and being a coder and writing code as the environment for agile. And I think there are a lot of other things we have to worry about. We have to worry about the data and the databases. We have to worry about the people using the system customers of the system and the other stakeholders. We have to worry about the hardware. We have to worry about I have a special name for programmers soft crafters, not software engineers. They're not engineers. They are craftspeople. I hope they are very good craftspeople, but they are soft crafters and plumbers and electricians do not make a skyscraper of 100 stories engineers and architects do. Okay. And there is even legal things laws we have to respect. And cultures we have to respect. So, there's just a whole lot of things more than the logic where more than the code and we and what I see is everybody is thinking about the code and writing the code and things like that. They're thinking like soft crafters programmers, but they're not thinking about the systems. Okay. So we need systems level thinking, even if our main job is programming and our main interest is the code somebody. Let's call them the systems engineer, the project manager. There, there is no word for this at all in things like scrub product owner really is nowhere near this case you wonder take a look at the description. We need somebody to manage the system. Let's call them a product owner and to architect the system. Let's call them the systems architect. And in fact, we need to do what is called systems engineering. Point number three of 15 stakeholders and I'll get back to this later. But let me give you a little first definition stakeholders are anybody or anything, which has a requirement for your system. Okay, so a law which says you must protect privacy is a stakeholder. It's not a person, but it has a requirement for you. So here is a long list of stakeholders. Every medium and large scale project has at least this many critical stakeholders critical means, if you don't make them happy, they can kill your entire system. They can make it illegal. They can make it so nobody can buy it or use it. Okay, so I believe we need to move away from users and customers and user stories as too little. We need to move over to stakeholder experience, not user experience stakeholder stories, not user stories. We need to. This is part of being systems engineer. We need to take into consideration all those factors, which determine whether we succeed, or fail. If we only look at the code, we fail. Look at the fader rates Google agile fader rates standish group for example, and you find horrendously high fader rates, due to, in my opinion, not using these engineering methods and being too much of a programmer and too little of an engineer. There's something else here. Many stakeholders, many qualities or values I call them these are stakeholder values these are the top 10 critical ones they're all quantified in my world. These are the costs, for example, future maintenance costs not just capital costs. And these are the top level architecture or strategies, and each one of these is related to one or more qualities is related to one or more costs is really and the qualities is what we're delivering back to the stakeholders. Okay, the qualities are the values that the stakeholders have. So it's a pretty complex picture, and we're using an app or a tool to keep track of it here called val plan. Point number four. If we have to think in terms of the cost effectiveness of our systems. Now, effectiveness. That's for me multiple values the security the privacy the performance the usability multiple values at the same time. And then there are multiple costs money now money later time and effort now and later. Okay, and in a way there's a little equation here, we can call efficiency. And it is the sum of all of these values, what we're giving to our stakeholders over the sum of all the costs types, all the resources. And we, in particular, our architects need to be looking at the value to cost ratio, the architecture. There's a chapter in in a book I've written I'll give you a copy of that free but there's a video going into this point more deeply. Now, this slide. Do you have an agile method that can handle 10 top objectives, quantified and five costs at the same time. Although I don't think you do. Here is a tool called an impact estimation table. It's in my books. It's in. You can. If you're interested you can read about it, but it's a tool is basically a spreadsheet. But on this axis we have any number of critical values or qualities, which are quantified. Here is how bad we are this number. Here's how good we want to be in the future. Here is a set of architecture strategies solutions designs, call them what you want. But they're the things we're going to do in our system and build or acquire in our system, which, if we do will give us some more of this value and more of this value and more of this value and more of this value and it will consume some of this cost and some of this cost. Okay, so here is actually a numeric way of looking at the multiple values of any design or architecture towards any set of quantified critical values or probabilities with respect to any set of long term short term cost people time money and using these numbers, we can actually compute the values to cost ratio, and we can point out the number here is the highest value to cost ratio. The highest value to cost ratio is a good way of prioritizing and saying, we will do this strategy first in the first prince, because it will give us the most values for the least costs. Here's a way of simplifying this table and simply bar chart. There's the sum of the values and there's the sum of the costs and these are different for different architectures being compared. I hope some of you if you get nothing you get this idea of the impact estimation table as the way of modeling complex systems and a way of engineering them. Point number six, do you have an enterprise architect. Some of you do. Many of you don't. It's not really a part of agile is it it's part of large scale systems development. Okay. Now, in this case I'm pointing to a case study from IBM systems journal from IBM federal systems division. And they had a problem. And some of you have the same problem that they had a fixed price contract with NASA or US Department of Defense for some software for maybe a ship or a rocket ship. And they had a fixed deadline for delivering it, and they had very high qualities for defense and space, the highest that were attainable. And every time they took such a contract, they lost money, they delivered light, and they had problems with the quality. So IBM went to the smartest guy in the room one hard and mills I call him the Leonardo da Vinci, a software engineering and said, Harlan, can you solve this problem. Can you always deliver on time under budget so we make money, the highest quality is for the largest most complex software systems and Harlan said, I'll try and he he spent years doing what is called the clean room method, you can look it up you can get books on it, etc. And now the one point I'm going to and they achieved that they achieved years on end, always on time. Imagine that always under the fixed price budget so they made money. Imagine that always delivering the highest qualities. Imagine that most people don't know how to do that. But this was decades ago, and reported in the IBM systems journal here is a link to the detail down here. Now, I'm going to make a very simple point here. The way they did it was none of the ways that are being taught in agile today at all. What they did, but this is agile. The their loop to deliver a navy system was 45 increments. In other words, 2% increments. Okay. Now, after every increment. They asked, are we is the quality that we want like availability of the system. Is that going up twice 99.98% that we are supposed to deliver. Yes, or no, if no, and we expected it to go up. Bob Quinn and the architect and say, Bob, you have to fix your architecture. Right now, before we do the next sprint, and you have to make it more effective so that we can can reach our architecture quality levels on on time. Or if, for example, if the one month sprint took two months, then they brought in Quinn and said, redesign the architecture. So it only takes one month. Okay. In other words, they made up to 45 adjustments in between sprints based on numeric feedback in relation to their numeric goals. And these adjustments allowed them finally to be on time under budget. Every time with the highest quality space and military systems. This should be taught in all universities for all large projects and certainly for software, but it is not the professors don't teach it. They were never taught it. They don't know about it. And this is the best agile method in the world, except Mr Musk, as I will talk to at the end, has also taken into use basically the same methods for space X and Tesla. Here's just another one. This is that they use the same iterative process to build the initial architecture as a series of steps until they think they have a good starting architecture before they do their sprints point number seven. And one of the largest adopters of my methods my planning language or plain which which quantifies the qualities and has the impact estimation table is Intel. They have been doing my methods corporate wide with over 20,000 engineers for 20 years successfully. But one man there Mr Terzakis likes to do research on my methods as they're used in practice at Intel so here's a research paper you can all have. And I give you just this one idea. So, first they, they know that a primary source of problems is badly written requirements, which then get to the architect which then does the wrong architecture. And so, basically, they do my quality control methods specification quality control. Okay, which is a simplified form of the inspection method. And they apply it to my planning language specifications which they teach everybody on a two day course. So a group comes with a 31 page requirement document, and they find 312 defects these are violations of the rules of the standards. In simple terms those standards say the requirements must be crystal clear numeric. No fluffiness. Okay. And this means that our 10 major defects per page page is 600 words, not bad actually quite good, because language forces you to have a good level to start with, but it turns out that Intel has calculated that they need to have a level of 2 per 600 words maximum. Otherwise, it doesn't pay off to go into architecture and design chips. So what they do is they say no exit your, your requirements aren't good enough, and the team tries again and again and again and again. This could be some weeks later, a 45 page requirements with only 10 defects, in other words, 0.22 gets exit, meaning it can be used for other purposes to can go to the architect. By the way, they have now reduced 98% of the incoming defects that were here in the first one. Okay, so this is a practical example of using my engineering methods in a very good engineering corporation, Intel, and there are more other corporations like Boeing and Judith Packard I could name right away. You will find case studies of my clients succeeding with the methods in the books. I'm giving you for free. Point number eight. In the way I already went through this, but maybe an enlarged version. So here we have the impact estimation table. Here we have different architectures. But in this case, we're going to consider the architectures to be possible sprint deliveries possible increments. Okay. And what we're trying to do is estimate how good is this architecture for this particular goal. And the answer is it gets us 50% of the way towards the goal. In other words, halfway between 50 and 90% of the numeric goal. And the same architecture has a beautiful side effect. It gets us 57% of the way towards this goal. And it gets us 53% of the way towards this goal. And it gets, et cetera, you see it. So wow, that's a really good design or architecture. Have you ever thought how to really evaluate a design. This is how you have to numerically say how good it will be and later measure how good it is in relation to your critical quantified objectives. As you know, the agile we know today doesn't try to do this at all. It is not engineering, and it does fail too often. And we've got to stop this failure by becoming agile engineers. You've got some great engineering universities in India. Maybe they should start teaching agile engineering. And I hope I'm talking to some of the professors right now. And I will help you with written materials and slides and any way you like to make the transition to teaching these ideas in India, if you just ask. So, yeah. And then here we have the rating of the costs. And here we have the computation and green means this has the best values for money. Therefore, we should, if we're smart, we should do this first, we should do this early. And even if it's a little bit disappointing, maybe it won't be so bad. If you take a disappointing one, and it's disappointing, maybe it's terrible. Point number nine, in simple terms, it's time we stop doing kids stuff with yellow sticky culture. It's time we digitized our thinking, as I've just shown you examples of digitized our planning for our agile systems and our management of the projects. And I'm, I am working with investing in and my methods are being used in next generation artificial intelligence, using ontology semantic triples the solid standard from Tim Berners-Lee Web 3.0. And I hope we can say bye bye yellow stickies. Those are for kids in their sandbox for small projects, no problem, but the large projects, not good enough go to graph metrics.com and take a look at that. Number 10, meet my friend Eric Simmons. He's the man who spread my methods for 20 years at Intel. He personally developed the courses taught the people coach them and also just made sure it worked in practice. He also wrote the forward to the competitive engineering book. Now, he and I had a little conversation about scaling up agile. And I said, I don't like safe. I think safe is terrible. Badly thought out chaotic method. And I think my methods already scale up better. And he replied to me in writing. Here it is. He said, Tom, your methods don't need to scale up because they are scale free. They all and we have proven this on small and large projects at Intel in practice for 20 years. Okay. Wow. I didn't think about it that way. Now I'm writing a new book. Here's the link to I'm in the middle of writing it. It's called simple. Okay. And we have a special chapter there on scaling where I've tried to work out the theory of why are some methods scale free. They work at any scale. And why are some methods not and the simple answer is what I call black box theory methods that look outside the black box, no matter how big and complex the inside of the black box are will work at any scale. I wonder if some of you picked up the idea. Anyway, read of the black box theory of scaling of methods in my new simple book and you can follow the writing of that book. In the next few weeks, I hope to finish it. Here's just a practical example. This is the same impact estimation table in use at a very small company of total 67 people but operating on the international market with media software and development staff is 13 programmers and three testers and they've divided their people about 16 people into four four person teams. Each team takes a quantified set in this case very many usability things but here's some testability and backwards compatibility. They take some quantified goals here's the quantification, and they work on them for a quarter of a year in weekly increments, and they measure cumulatively how far they have gotten this is actually week nine of 12. So they bought 67% of this 100% of this 107% of this one, and then based on this feedback, they decide which goal they're going to work on usually the weakest ones like here's a zero. So we need to work on this is dynamic prioritization, and they achieve by the end of their deadline which is the quarterly release of the software to the world, they achieve extremely high qualities on in about 20 areas. In the first year of the use of this method, they blew away all their international competition, they wiped them out and bought them up and succeeded on the market and they directly credited on their website in public our Evo method. This is just simple proof that even on small scale agile engineering also works, you can read the detailed case study there. So, 12 principles of agile engineering. Now, let's see. How are we doing on time. We've got to be. Let's see. And I'm going to look at my watch. Yeah, okay. So we're pretty good on time. I have an alarm going in about 10 minutes end of the 45 minutes and then we have a little bit of leeway here but okay. So this is from a book called value agile and here is your free copy. Here are some slides on it and here is even a video of me explaining value agile or agile as it should be. Okay, and here are the basic principles. Now, actually I've been through these principles in my earlier part of the talk so I can save time, but I have condensed the basic idea into these 10 basic ideas, and these are the basic ideas then of agile engineering. I've been engaged with a group called Essence with Eva Jockerson who invented URL and other things. And he in his old age, he decided to become an idealist or do what you Indians call save up. Okay, and me too. I'm 81 years old. Okay, and I'm going to do save up is when I'm sharing my ideas with you. And even got a great idea. He said, let's stop the agile wars of my method is best get certified in my method pay me. He said this is silly. Let's have a library called Essence, and let all those who will donate their methods, give their methods for free to everybody in India and everybody everywhere else. So for example, Scrum has done this. Okay, Jeff Sutherland. He's on board there. I have done this. And so I've taken all my methods and I wrote a special booklet you can have a copy of it, called Simplan. And actually, I'm having a meeting later this evening with the people who are moving my ideas which are organized in this book over to Essence in progress now. But if you like this book is a way of pick and choose any of the 100 micro acts, and you can bring it into your method without changing your method. Okay, one idea at a time, if it works for you, it's good, and it's free. And, you know, bring your own method. Okay. Now point 14 out of 15. Not too bad. Stakeholder again. So I have a, I finally did what I've been promising myself to do for years. Last year, I wrote the stakeholder engineering book, which is how many pages is it's a lot 170 pages or something like that. Here is are the principles of stakeholder engineering. Okay, one of them is the stakeholders are so many and so complex that you really need digital tools, not yellow stickies to keep track of them. And you need a very clear definition of who that stakeholder is and what values they hold, and you need numeric information, how much security do they want, and when do they want it. That's numeric information about the stakeholder values, etc. Again, if you want my one page summary about stakeholders. Here it is. Nice little diagram where I analyze stakeholders in relation to threats and security. No more time for that. And so we have must methods. Now, about a year ago, must did a star based tour. And during that tour, he said, this is my I have five principles. Here's my number one, two, three, four, five principles and I thought, wow, must hasn't yet written his methods book, but I could. This was then written down. I made my own notes but the guy with the video made his notes, and we finally wrote down must five principles. Okay, and here they are. And I like must principles because, well, because they're the same as my principles, right? But he has some fun principles, for example, requirements are wrong. It doesn't matter who gave them to you, like your customer in Europe or something like that. He says it's particularly dangerous. Even if an intelligent person like Elon Musk gave you the requirements is you might not question them and say maybe they could be improved. Everyone's wrong. Even Elon Musk. All designs are wrong. Even Elon Musk's. It's just a matter of how wrong. Wow, wow, wow. And there's more here. By the way, he ends up with everyone should be a chief engineer. What does he mean, he means the same as I started this talk with everyone should understand the larger system and how it all hangs together like Musk does when he works in detail. Okay, so he here is just a reminder that the principles of Musk are as far as I can see the same as I'm trying to encourage you my my language ideas. And I think Musk is the greatest agile practitioner of all. I think, forget me, forget my ideas. Don't read my book, read Musk's methods book, which I give you for free. I rewrote his because he was just spouting off orally while walking around his his spaceships, but I rewrote to make it clearer what I think Musk means. And I detailed here's the detail on the requirements. Here's a a language requirement in detail quantified. Okay. I rewrote the design. I rewrote the dynamic optimization. I rewrote accelerate. Here's a fun picture. Here's the chairman of Volkswagen being jealous that Musk in his German factory will go three times faster pushing the cars out. And they even dream about Volkswagen. Not bad for a beginner because I believe Volkswagen's been at it since the eye before I was born. He's pretty good. These principles work. Okay. Automate, but as some of you know, in the for the Tesla Model three must automated too much too fast and he had to go back and systematically work his way up to automation or not automate very interesting study I drive the Tesla Model three for one year now. It is perfect. I've not had a single fault in it. Not bad for an automobile. I wonder how the Indian automobiles compare quality. So, yeah, here's this idea focusing on the big picture. Some of his young employees were encouraged to do that focus on the vision of well getting to Mars or something like that. Here's something else that's little known. Musk is actually fanatic on safety of the passengers in the cars and safety for people. And here are the 50 safest rated cars in the world and model three model S and model X are the three safest cars in the world. How does he do that. He doesn't do it by testing and debugging. He does it by. Okay, there's my 45 minutes. I'll put it on snooze that gives me nine minutes. If I need it, but I won't. Musk hires the smartest safety engineer he can find and says, I don't want you to merely meet the safety standards of California. I want you to design the safest car ever built. Would you like to work here instead of for that stupid general motors you're working for now. And the ambitious young architects is I want to work for you. I want to design the safest car in the world, and they did it. In other words, they do it. They do it through architecture through design through engineering. They don't debug a bad car after it's rolled off. That's what we are still doing in software. We are testing and debugging that software rather than designing the software to not have bugs in it. That would be called the defect prevention process, which you'll find I've written about. So engineering is complex. Some of you will be a little bit overwhelmed with what I've presented some of you will say this is not for me. I'm going to go back to my coding. Sorry about that. I hope there are a few of you leaders in teaching and in your companies. It said, this is for us. This is an agenda for India. We will lead the world in software engineering. We will take in the into use these ideas before most people outside of India have woken up to the idea you still have a chance. So here's the book I'm working on simple pre copy. There it is. And recently we made an attempt to simplify. We all shall away and I were talking about the iron train triangle and getting very unhappy about it. So we defined a five of the pent up with five notions where we brought in things that are not in the iron triangle like the idea of designs, the idea of quantified values, the idea of efficiency that I talked earlier, and the idea of far more resources than simple money and time. So if you like this is the definitions of all these are right here. But if you like this is my new simplified model of software and systems engineering. And it's quite fresh we invented the whole thing from scratch, just getting angry at iron. Triangles and their comments about the in August this year. So now I'm done with my presentation. Oh, here's another free book. If you absolutely insist. Everybody talks about complex and and complicated systems. And I believe the problem is not that the systems are complex or complicated. I believe we don't have the tools to see and understand them. We put all 100 such tools in a little book called techno scopes, which in fact our engineering tools for looking at the black box and understanding what is inside. So in other words, I do not believe in the theories that of complexity and complication is a problem. The problem is us. We don't have the tools to see complex systems and understand them. So here's my talk. Oops, go back a slide, but these are so here's a reminder we did. And we then do we have a how many more minutes do we have for questions. Go ahead. Yeah, I think it's first of all, thanks a lot. Tom, that was amazing. I didn't realize we ran out of the 45 minutes so quickly. This lasted a little longer. But I'm sure you'll be in the hangout table and, you know, your knowledge is accessible through all the links you've provided greatly appreciate. First of all, I think I'm quite amazed how you've taken care of your stakeholders by putting these QR codes so people can scan and get access to this very easily. I thought that was very thoughtful. You know, that you know other folks can kind of copy. Cool. I think, again, I can, I can go on and talk about everything I got out of this talk, but I think there are a few questions we should get to. So I'll kind of quickly jump straight to it. Tom, if you're okay with that. Yes, go ahead. Cool. I think we could stop sharing your slide so people can see you full screen. The one question I saw it was give me an example of language. Yes, yes, so then to answer the question I need the slide so I move back to one slide. Here is an example of the planning language playing which which I started inventing in my software metrics book 1976. So I've been doing it for about 50 years. This is the language which Intel has adopted, for example. And so here is one requirement of a value. Here is a statement of the ambition level this is what we call the bullshit level it's it's almost the same as user stories by the way. If you go to engineering would say, if define a scale of measure. That's the big trick. And I teach this in my book so here is a defined I don't just say the car is fast I say, we will use miles per hour or kilometers per hour as a scale of measure. And then I say, we will measure it with this speedometer on the car, or maybe the police will measure with a radar system. That's the meter specification. Then who are the stakeholders who care about this United Nations Children's Fund, etc. And what is the status at the moment, we are at 50 on the scale and what is the goal. It's to increase from 50% to at least 95% by 2019 in this case but that was then. Okay, so here is a, here's a practical example of a value or quality requirement using plain which. Now, the, this is also plain which this is the sum of values versus the sum of costs for different architecture. That is plain which here I showed you the simple example using a simple spreadsheet of the small company. They are looking at one design on sprint nine and estimating it will give us 50% of this goal. And they actually achieve 95%. That's the feedback and measurement. This is plain which in that particular example. I showed you a few more impact estimation tables that is playing with so in a way so the end. And then of course, all of the free books I've offered to you, including the competitive engineering book. Yeah, competitive engineering book has a cover that looks like this. Here is the book, and you can, by the way, there is an Indian edition of the competitive engineering book for only 400 rupees or something like that. If you want a paper copy cheap in India, you can get it, but I'm also offering the PDF absolutely free in this set of slides and the, the competitive engineering book is 500 pages with plain which it defines language. So that's the answer to that question. All right. Thanks, Tom. I think we have a few more questions so I'll quickly go over here we have ankit agarwal so ankit is basically saying fascinating talk more than what I was anticipated. This, the question basically here is how does one change the mindset to question owns belief that I may not know everything. Okay, changing mindset is difficult. I've been trying for 50 years and I succeed some places like Intel and unit Packard very mature motivated companies. I also succeeded with my friends at Tata consultancy services. And there's a story about that on the second slide. Okay, so some very smart Indians have received them. But most of the world doesn't know about these methods. They don't try to do the methods they're not motivated. Why not. There's a long answer to this question I'll give the short one. You get people get paid for failure and for delivering bad systems. Why should they change. What if you never got paid, unless it were delivered to the highest quality on time under budget. Maybe you would be motivated to use these methods. Then, if they help you. So, so the long story short, people are not motivated to change to better methods. And the world allows them to use the ridiculously bad agile methods they are currently using and still get paid for it. Somebody has to get smart and stop paying for failures and delays and bad quality. And then people say, but how are we going to get paid and somebody said, Oh, Tom held the talk at agile India and said he thinks he knows the answer. Let's try. And those two have tried my methods like Intel unit Packard Boeing IBM and TCS have succeeded. Awesome. All right. One quick question from me Tom. I think you referred many times in your talk the importance of having, you know, really smart people really good people. You know, I think you also talked about how Musk uses hyper tries to hire the best engineers. What is your advice to anyone who is trying to build a team and is looking for hiring the best people. How, how would you suggest they go about it. I, I think smart people know smart people. And I know India has a hell of a lot of smart people. They're not difficult to find. Okay, now, if you give smart people bad tools, they'll do bad work. One test might be at the interview. You give them my competitive engineering book for free. And you say, come back for a follow on interview and tell me what you think of this book. If they come back and say I think it's great ideas we should do them, then I would recommend you hire the people. If they come back and say this is too difficult. I like scrum or I like safe, then I think they're not smart people and you should not hire them. That's a great litmus test to to figure out who to hire. Appreciate that. I think, by the way, we could, that was a little bit self serving. Hey, give them the must methods book. And if they come back and say I love these must methods, hire them. Sure. Awesome way to recruit people but as he says so that's great. All right, I think what I'll do is we just a little out of time so Tom if you don't mind, we can move over to the hangout table but before we do that I just want to thank all the participants for joining in today. And I want to thank Tom for this wonderful, wonderful insightful talk. I appreciate it. Thank you very much. One thing for people who don't get their questions in. I have an email, Tom at the guild.com. And I invite you. No charge to ask me questions and have discussions. Any time. Be my guest. I'm amazed how quickly Tom responds. Trust me on that.