Aaron: What one thing was most important for you to mention in your acceptance speech?

Jim: When Brian told me the main thought that came to my mind was, “Oh, boy… what am I going to do with this?” It is the only award that the Agile community gives. I had this overwhelming sense of responsibility, “How can I live up to this?” For the acceptance speech itself, I felt it important to mention the other people out there who are also contributing.

Aaron: How did you get involved in Agile and why is it important to you?

Jim: In 1999 I was asked to lead a team and in looking at options for methods to use on this team I decided on Feature Driven Development. Software process is something I had been interested in for a while. One of the people on the team said to me, “Let’s use XP.’ and I said, “What? What is this?” and he said, “Well you can read about it on Ward Cunningham’s Wiki” and I said, “The what??? Well, you know we’ve already got this established so I’d like to keep on going in the direction we’re going if that’s all right.”

We delivered that project. It actually got canceled part way through. Someone wasn’t paying attention to the budget. Which was one of the learning experiences for me about how much is involved in just getting a software project out the door. It was canceled but since we were doing iterative development we delivered the software anyway.

I started looking in to Extreme Programming and reading the stuff on the Wiki and it looked really interesting. Some of it looked absolutely ridiculous like pair programming was obviously stupid and incremental design, another idea that could not possibly work. It was proposed by people who I had a lot of respect for; whose language and thoughts resonated with me and what I know about software development. So I had to try it. Even though it was obviously dumb and couldn’t possibly work.

Aaron: How do you learn most effectively?

Jim: By trying things and seeing if they work. The next project I was on I tried a few things, like test-driven development. They worked really well. That company called me back and said, “We figured out what happened to the budget, come back.” They had misplaced their budget. I said, “I’d like to finish this up using Extreme Programming.” We did all of XP by the book as close as we knew how. I wrote about it on Ward’s Wiki. At that time it was fairly rare. There were a lot of people interested in Extreme Programming, but not a lot of people actually doing it.

I tend to write about my experiences. Shared experiences are the best way to learn. You know, direct experiences are the best way to learn and then the second-best way is to learn through other people’s experiences. Simply declaring an opinion doesn’t do much for me.

Aaron: Who are some of the funnest people that you’ve collaborated with?

Jim: I have enormous respect for a lot of people in the Agile space. Alistair Cockburn saw some of the things I was writing. He saw that I was located in Salt Lake City so he invited me to join his Round Table. I’d bring in my problems and we’d talk about them and I’d say, “That can’t possibly work” and I would go away and try it and come back and say, “Well, you know… that worked. Here’s what I did and now here’s the problem I’m having.” Which I wish more people would do. I wish people would say, “That can’t possibly work” and try it and find out. It seems like the mode is, that can’t possibly work and turn off brain.

That project gave me the opportunity to see how Extreme Programming works over the long term with a fairly large team. It was 8 programmers on this team, on average. We had a substantial code base by the time I was done with it. We delivered every three weeks from the beginning. Never missed a commitment.

Part way through this project I was hired to create a new team here in Portland. I hired Rob Myers to work with me who has been an XP coach for years. I really enjoy working with Rob. Diana Larsen and I do a lot of collaboration and she’s just fantastic.

I think the thing you’ll see in common with everyone I work with is they are all passionate about doing a great job. They are all passionate about seeing the industry improve. The people I’ve mentioned and others too, are about making life better for software developers and projects first.

Aaron: Is that what you find important to you about Agile methods?

Jim: In 1999 there was absolutely no monetary benefit in doing this stuff what so ever. I did it then for the same reason I do it today. It is the best way I know of for doing software development. After you’ve worked on an XP project for a year and a half that was really successful, working in any other way is like licking sand paper. It’s just really not fun. Doesn’t taste very good, either.

Aaron: What are some of the approaches that you used that allowed people to really pick this stuff up and run with it?

Jim: The biggest thing that I’ve always found is total immersion. It is my preferred way of working with people. There is enough of a mind set change involved in this work. The most effective way I’ve seen of conveying that; is to simply work with somebody who really knows what they’re doing.

Training some times works. It can inspire somebody who has got the idea. You can pick this stuff up from books. I didn’t learn this from anybody. I learned by trying and asking for help and talking about my experiences. And reading about it. I know it can be learned that way. What I’ve found in the ten years I’ve been helping people do this is following a leader who has done it before; having them work with you directly is by far the most effective way of getting it in to place quickly.

Aaron: Since winning the award, how do you feel your opinion or perspective on Agile has evolved?

Jim: I think it’s deepened. I’ve come to have a broader understanding of it. I’ve certainly seen the community change in that time. It’s now a moneymaker and so we’re seeing opportunists come in. We have a lot of people who don’t know what they’re doing. There’s a huge amount of marketing rhetoric out there combined with some fairly incompetent people. Even the competent people, the ones more interested in making a buck, are selling what sells rather than selling what works. That really bothers me. I do want to see the state of the art improve.

Aaron: How do we highlight these incompetent people and weed them out?

I don’t think naming and shaming is necessarily a good idea. Any publicity is good, as the saying goes. I think talking about the problem and establishing a culture in which certain things are respected and others are not is possibly one way to go. My hope and dream is that in the Agile industry we become synonymous with excellence.

Aaron: How do we get to that place where Agile is synonymous with excellence?

Jim: It’s a matter of culture. The more people who talk and write about Agile, who take the attitude that we’ve got to compromise on doing good work because nobody will accept it, the more Agile is going to become synonymous with mediocrity, for not working. We want to avoid the situation where we say, “Yes you’re all in the same building but no, we’re not going to take down the walls because that will make too many people uncomfortable. You don’t want to put people together, that’s ok. You don’t want to assign a product owner, OK. No worries. Your testers need to be in a different division? OK, no problem. We’ll make it work for you. We’ll take this thing and just have the domain experts write up a requirements document and hand them to the developers. They’ll do development in “Sprints”. We’ll call it “Sprints” so that way it’s Scrum, right? They’ll hand it to the testers and the testers will follow one “Sprint” behind and when it’s ready will show it back to…” That is the type of attitude that sells because it’s easy.

If we go the other direction, if we as a community say there are some situations in which Agile is simply not appropriate then we will sell Agile less often. We will have fewer people using Agile. By doing that we’ll have more successes. I would much rather have the Agile community being known as a community that is a little up tight, a little exclusionary, that always does great work.

Now I’m not saying that you have to do all those things. You don’t have to do Extreme Programming to do Agile although you do have to do some sort of XP-like engineering practices. It is possible to have a distributed team that is Agile. The further away you get from these Agile ideals of having a collocated team, of having a dedicated product owner, the harder and more expensive it gets. What I see happening in the filed is the further people get away from that, the more they water it down, the easier they try to make it.

The reason XP and Scrum say, “have a collocated team” is because we know the secret to successful software is having a cross-functional team that communicates really well. We don’t say collocation because Agile wants you to be collocated. We say collocation because that’s what leads to really good communication.

The other thing that happens when you have a collocated team is that you have unintentional communication, or unplanned communication. I’ll be working on something and if you’re sitting there, I might mention something about it to you. If I have to call you I’m not going to bother you.

If we’re going to work with an organization that does not have collocated teams, we can’t just say we won’t do that piece of Agile. We need really great communication. How are we going to solve that problem in a different way? Instead what I see people doing is saying, “That’s hard. We’re just not going to worry about that piece of it.”

Aaron: What are you working on these days?

Jim: I’ve decided to focus my business on the people who are interested in being great. Who have that desire to change their world so that they can be great. I also am working on a startup with Arlo Belshee and Kim Walmark. In my copious spare time I am noodling around with a new test framework to replace FIT.

Aaron: How do you know this team is capable of greatness?

Jim: I think every team is capable of greatness. At an organizational level I need to see real desire. In the end what is required for greatness is a willingness to try stuff. I think the ones who want to be great are willing to shake things up a little bit. I’ll hear things like, “Of course we have to fit in to the existing corporate structure and we need to go through our phase-gates.” And I’ll say, “What you really need in Agile is simultaneous phases” and they’ll say, “Absolutely, we should have that. But we need it to fit in to our lifecycle because if we don’t nobody is going to be happy and we just can’t afford to make those waves.”

Aaron: Talk a little more about these simultaneous phases, if you would.

Jim: I think simultaneous phases are the secret sauce of Agile engineering. You have all aspects of software development, which are traditionally called requirements, design, coding, testing, releasing, operations and support. Those are generally laid out as separate phases. That’s the classic waterfall lifecycle. Even people who do Agile methods like Scrum tend to take this classic phases and just sort of smoosh them down in to a shorter cycle.

Aaron: I like to call that the rapids.

Jim: Yeah. The rapids. Exactly. Simultaneous phases are having the ability to do all these things, all at once. Doing your testing at the same moment that you’re doing your requirements at the same moment you’re doing design at the same moment you’re doing your coding, at the same moment you are making sure that you are operationally capable.

It is difficult. That’s why this work does require a mind shift. Because it is difficult, it’s the thing the opportunists are ignoring entirely. It’s not something that you can just teach.

Aaron: Or sell. It’s a little hard to sell, “Hey, you know what? This is going to be incredibly difficult for you.”

Jim: Doing your design, coding testing simultaneously requires doing them in very small pieces and doing incremental design. What’s difficult about it is that you really, really need to have your requirements experts working closely with the team. Cross-functional teams and collocation are necessary to make that work and those two things I think are really important and also something nobody wants to do.

Even when I work with Scrum teams that were well trained, they often don’t do cross-functional or collocated. It requires doing things facilities doesn’t like, that the corporate structure doesn’t like. This is where the big wins are. The big wins are not in doing work in two-week Sprints. The big wins are increasing your communication, working simultaneously, because simultaneous phases are also a way of improving that communication so that you don’t have a throw-it-over-the-wall mentality.

Aaron: It sounds like not only are you talking about the walls between our traditional development and QA phases, but also between business analysis and development or design. All of these things blend together, requiring that collocation.

Is there anything else you’d like to mention or discuss?

Jim: I’d like to close by saying that the Agile community and the software development industry in general would be better served by people seeking excellence than trying to fit in.