 So, this is going to come across as a really sort of old curmudgeon talk, but it would be nice if some people had actually tried Agile. And that's not completely fair. There are quite a few teams and organizations out there who understood that Agile was a fundamental paradigm shift. It was a different way of looking at how to build software. It was a different mindset. And they have been and are continue to be very successful, working very closely with their users in fast feedback loops, kind of continuously checking into main, not having long running feature branches or any of that sort of nonsense, not doing pull requests or any of that garbage, but just working very closely with the users, tight feedback loops, and able to adjust very quickly to any changes that happen. And that's great. But there's also a lot of teams who didn't get that memo. And I think many teams who think they're Agile aren't Agile at all. Scrum is not Agile. It's not the same as Agile, and it itself is not particularly Agile the way it's implemented. So here's the test, you know, am I Agile enough? Suppose there's a big change in how you understand the user requirements. There's a big shift in technology, a big shift in the market. Can you quickly and easily adapt to that change? Or not? Can you cause that change on purpose and then adapt to it so you have a competitive advantage? That's what Agile is all about. In the book Practices of an Agile Developer that I wrote with Dr. Venkat Supermoneyam, we said that Agile development uses fast feedback to make constant adjustments in a highly collaborative environment. That's what it's about. It's not about sprints. It's not about planning poker or story points, God help us, or any of that other rubbish. It's about getting fast feedback and adjusting constantly with the whole team, with the user, with the sponsors in a highly collaborative environment. If you're only getting feedback every few weeks at the end of a sprint or months, even worse, that's not fast enough. You can't adjust. If you get feedback and then ignore it, don't do anything about it because there's no ticket for it or what have you, then you're not making adjustments. If you're working individually on tickets, you're not collaborating. So all of these things aren't Agile and aren't very productive. And frankly, aren't a lot of fun either. So it hasn't quite gone how you would have hoped. Not exactly. But we have made some progress. Back when Dave and I wrote the first edition of the Pragmatic Programmer back at the turn of the century, we advised everyone to make sure that they had a build machine set up in the corner, a spare PC that would sit and you could check in and it would do what had been the nightly build but do it during the day as you checked stuff in. And that was kind of radical. The idea of dedicating a developer machine just to do builds was a new and novel thought. That was also 26 years ago, 22 years ago now, right? Now everyone's much more comfortable with the idea of having that as a pipeline in the cloud. You check in, it trundles, it does, it's CI, CD, and boom, you've got a deliverable that you can test with or ship or whatnot. So on that front, we've made really good progress. Now if we could get to some of the other issues involved, we'd really be going somewhere. But it's a slow slog, but I hope we'll get there.