 So this is the fourth presentation I'm doing this week and it ties into with some of the others. If you didn't get a chance to see some of the others, I'll try to refer to some of the relevant details as we hit things. This is called the secret assumption of Agile because there's something that I realized after I was doing Agile for a while that actually, you know, the Kent Becks and the Ward Cunningham forgot to tell us when they started out. And one reason is that they seem to be successful and very obvious things for them, but not so obvious for some of the rest of the engagements I've been in. So Agile, overall, is quite productive. I went through this case study a bit in one of my earlier presentations where we were at Nationwide Insurance. We had a traditional waterfall company, actually an Indian vendor, one of the best in the world at doing waterfall bidding for a project. And because the trial was a bit too long, they asked it to be a bid Agile. And we bid an Agile project at basically half the cost, even though the labor rate was three times higher. So overall net effect is that we're about, the Agile process was almost six times more effective than the waterfall process. And this is, again, a waterfall process from one of the best, you know, level five waterfall companies in the world. And so this presentation is a little bit, what were we doing that gave us a six-fold productivity improvement over these traditional processes? So this basically is the kernel of this talk. It's what happens here. And the first thing that really is, this is almost a secret assumption of Agile is, you really have to be able to write code that's easy to change. And there's a style of programming that was sort of born with the Agile movement that we haven't necessarily captured as we've carried the Agile processes along. That we seem to be writing code in another old-fashioned way, a little more of the waterfall way, under an Agile process, and we're wondering why we don't get great results. And I think a lot of that has to do with being able to write code that changes. So I'll talk mostly about that. We'll get into a little bit of lean management and using processing power. But, you know, the key thing about that environment, the reason we were faster, was because we wrote code in a particular style. So this was kind of when I was trained. This is one of my early mentors when I was in IBM. I started in Objects about this time frame. So I've been doing Objects now about 25 years. And this was very profound. And this was Rick Dina Telly. He actually worked for me at the time. And he said, Objects are only good for programs that change. And if you think about it very quickly, is every program that's interesting needs to change. And this is his way of saying that, oh, by the way, Objects are really good for almost every interesting program. Now, there are also other techniques for doing programs that change. Functional programming has some techniques. I certainly have sort of systems like Prologue for doing rules-based systems. There are other systems doing that. But Objects are particularly good for programs that change. It was good.