 I've seen a couple talks this morning and most of them are 90 minutes. This talk is one hour, but I've got 90 minutes worth of material, so I'm just going to deliver it about twice as fast, or I'll cut stuff and try and make it so you don't notice. In way of short introduction, my name is Jeff Patton, and I've been in agile development since there's been agile development. I started with a process called Extreme Programming in 2000, the term agile was coined in 2001. During the 1990s, I'd started as a developer and well, I had a bit of an art background, so if you're a developer with an art background, that makes you the UI person. And if you're a developer with an art background and you can talk to people, that eventually makes you a product manager. And throughout the 90s, I did that, and then I started this Extreme Programming stuff in 2000, and I've been working with agile development ever since that term was coined in 2001. I need to come clean with you here, for everybody here. I have hated agile development since the very first day I encountered it. It's a real problem. I remember when I first started with agile development, I was immediately presented with the choice that I could either be a customer, is what they call the role, in Extreme Programming, product owners, what they'll call it now in Scrum, I could either be a product owner or I could be a developer. And I tried to explain it, well, I did both before and that wasn't okay. That's not the way agile processes work. So I said, fine, I do this because I like creating products for people, and so I'll be a customer. And then after spending a little bit of time as an agile customer, I was ready to kill myself because, well, I'll explain in a little bit more detail later, but typically an agile process is driven by placing someone with a lot of domain knowledge and in that customer role, and that person is responsible for telling the team what to build. That does not work. What works is spending a lot of time with your users and your customers, and, well, when I first started with agile development, there wasn't much interested in that. So I said, that's it, I've had it, I hate agile development, I quit, and I said, well, if you'll stay, you can be a developer. And I did that and that was great because I could do the work and enjoy my job and not have to care whether the product was good or not. All right, let's fast forward because I wanna talk about a way of working that is starting