 Welcome to Agile Roots 2010, sponsored by Version 1, Rally Software, Virio, Mirsis, Agile Alliance, and X-Mission Internet. No-one wants your stupid process by Jeff Patton. I'm Jeff Patton. I've been involved with software development since the early 90s. I started software development working with a company that was either wise enough or stupid enough to put developers working directly with end users and customers. I worked with a company that built commercial software. So the users of our system, there were lots of them. They were diverse, and really I couldn't count on getting the same story about what they wanted for multiple users. So we had to learn very early on that if we wanted a successful product, we had to listen, we had to learn, and we had to understand how they were using our software. So throughout the 90s, I built software and worked in small teams, and things worked pretty well. Let's see if I can make a clip this story a little bit. Right around 2000, I was lucky enough to get drafted into a company that was doing this weird new process called Extreme Programming. Jeff. And I worked with that guy there. Now that there's someone here that I worked with in 2000, this rules out all the lies I was about to tell. But I immediately hated, hated this company and hated this process. The first thing they made me do was choose to be either a smart person that understood what to build or a smart person that understood what to code, but I couldn't be both. I had to be either a customer or a developer. And because my domain knowledge looked too good to waste, I started as a customer. And after a couple months doing that, I was ready to kill myself. Because a customer in an XP context didn't meant I did what I used to do. It didn't meant I went out and talked with people, worked with customers, worked with end users, and worked hard to understand what people needed. It meant that I worked with a bunch of people who had strong opinions of what should be built. And we argued with each other a lot over what should be built and then tried to speak with one voice and work with developers to give them our stories. So happily, luckily this company let me become a developer and I was happy and blissful and I learned some good development skills, worked with some very good people and didn't have to worry about the success of the product. The product didn't succeed. The company ultimately did something with the product, but ever since then, I've been on a mission to take this process, to have these elements that I really loved and do something better with it, put it back together, get a process out or get a way to work out that let me both be strong from an engineering perspective and actually get a good product out the other end. So let's see if I can tear through a few messages I want to leave this morning to sort of set stage for the rest of this conference. I want to start by describing what I'm starting to notice over the last 10 years as the process racket, this thing we're doing to keep selling ourselves on more and better process. I want to talk about why this doesn't work, why off the shelf process doesn't work and why we keep falling into this. And then I want to come back to, well, how do we build a process that gets us something good in the end, bring it back into balance where it's partly about engineering and partly about just focusing on what a good product should be. I want to frame this and touch this back to a story. The story is about the CEO of a company that I work with in Brazil. His name is Juarez. If you're from El Paso, you might mispronounce his name as Juarez. But in Brazil, it's Juarez. Juarez is the CEO of a company called Globo.com. In Brazil, the global, the conglomerate is a bit like Time Warner in the United States. Globo owns newspapers, television, cable stations, radio stations, and Globo.com builds web properties that serves all these folks. Juarez started this as a small internet service provider and he helped bring this up from the ground up. He's a CEO that walks around the office, is well known, and everyone knows him. And one of the last times I was there happened to be on his birthday. That's a lot of people with Juarez's face on, because one of the things that they did on his birthday was make lots of Juarez masks so everyone got to be Juarez for the day. And yes, everyone in Brazil looks just like that. So they carried masks around to Juarez and surprised Juarez with a cake. And Juarez, everybody celebrated his birthday with him. This is a CEO that cares a lot about the business that he helped build. Right now they've got 23 teams that number between 8 and 12 people each. They're building lots of software and they build software that again supports newspapers, television stations, radio stations, all these things. And if you were to walk into this place, they are a model of agile success. Every team stands up, every team writes user stories. Every team has a scrum master, every team builds in short sprints and they are using strong engineering practices, test-driven development. Well, almost everything the agile community has prescribed they're using, but Juarez is, on my last visit, Juarez is not happy at all. Juarez helped build this company from the ground up and he knows that a long time ago everyone used to take pride in the product that they were building. They're building software that almost everybody with a computer in Brazil sees. It's the software that people go to to tune in to see what's going on on the World Cup. It's the software that people go to to read news stories from the newspaper and on the television news, it's the software you tune in to go to to see what happened on Big Brother last night. This is important stuff and Juarez is concerned that the software that they're building is not good and all he keeps hearing about is discussions about acceptance criteria and well it wasn't particularly good because acceptance criteria didn't say it had to be particularly good. They're running into situations where things are finishing slightly late or not on time where people used to rally and work together to get things done on time. He keeps hearing about well estimates and velocity and the velocity, well there's a magic, one of those magic eight balls where you shake it and it turns up and says velocity says no on the delivery time and he keeps hearing discussions about that. Basically he feels like the soul has been sucked out of his company and he wants people to start tearing again. Juarez talks with a guy named Danilo. Danilo is in charge of development and Danilo helped bring Agile development in. Danilo wanted to bring some sanity to the software development process and to a degree it really has. A lot better engineering process, a lot more steady pace. People are really talking with each other, but talking with each other using these rules of Agile development and Juarez talks to Danilo and Danilo says well the problem is the people in the product ownership role aren't doing their jobs well and it's their role to describe their product and say when it's done and we really need to improve those people. Now I shouldn't feel bad about any of this because that's how I get most of my work but there's something inherently going wrong here. Let's see if I can pick it apart and see if it makes as much sense to you as it does to me. So let's talk about this process racket that's going on. The process racket starts with an executive who's having real trouble with their process and they phone up a process expert and they say our customers are complaining because they hate our software. We believe that if we could ship more of it faster that would solve our problems and there's a process person that always has a bit of an answer. They've got a process that will fix things. This is where we enter the cycle. Let's see if those slides come up okay. I've a painstakingly produced these slides by drawing them on big cards. The process or the cycle starts with our process not working and we proceed to try a new process. After trying for a while things still aren't working at least not quite right. Some things are better some things are worse and happily we've gotten the help of a consultant who tells us that while we're doing it wrong we should try harder and if we try harder and we keep going around this loop a few times. Now for anyone who's been in the waterfall business for years this should ring a bell. I know that when waterfall doesn't work it was because we weren't doing it right and our job was to try harder and we'd get it right next time. We go around this loop over and over until finally we get fed up and we find a shiny new process and we start the loop again. It seemed like Agile might be immune to that sort of loop. We wouldn't fall into this trap of saying we're doing the process wrong but I'm starting to see lots of evidence that we are doing the process wrong.