EXTREME PROGRAMMING: AN INTERVIEW WITH KENT BECK

Q: What are the issues you see your clients struggling with?

KB: One of the issues is redefining failure or redefining success. For example, you think that you have a great idea for a project, and it's going to take you nine months to really have it ready for the market. You [may] discover after four weeks that you are going one-tenth the speed that you thought you would, and you cancel the project. Is that a failure or success? In many organizations, this is perceived as a failure. In the XP world, providing information that allows you to constantly make that decision after four or eight weeks (out of a nine-month development cycle) is what you're there for. In the XP world, you call that a dramatic success. Now you have this cultural mismatch between how outsiders are going to view your outcome and how you view it inside the team. A lot of people [clients] struggle with that. They think that cancelling a project is a bad thing, but I think that cancelling a project is a good thing -- as long as you cancel the right one.

There are many social problems that people are struggling with, and they manifest themselves in really bizarre ways; like when I hear, "No, we can't make a project room. We can't remove cubicle walls and have a project room where everyone sits together for most of the day." Now, the laws of physics aren't what make that difficult. The wrenches and tools are there specifically so that it can be changed. I think that there are many social issues hidden underneath the unwillingness to set up project rooms.

There might be a kind of stratification between the business people and the technical people. Like, "The business people don't want to sit next to the programmers." As a programmer, that's how I would see it. Or "We can't have the salespeople here because they make too much noise." However, you can learn how to manage noise levels. Or, you can have a little office to the side, for someone who needs to make a sales call. But it's really the breaking down of the social hierarchy and replacing it with a network of teamwork that, in my view, people are really afraid of. A lot of people are grappling with that issue today.

On the technical side, a lot of programmers sort of like being able to go into their little caves and not have much accountability. They have a big problem with weekly planning, very visible estimation, programming with other people, testing and integration, and being a continuous part of the process. There may be some resistance there.

Q: How do you suggest resolving these issues?

KB: My approach is really quite straightforward. I always ask two questions: "Is there a problem?" and "Do you want to change?"

I listen very carefully to the answers because yes and no aren't very interesting answers. Someone can mean the opposite by either answer to either question. For example, I was talking to a CTO of a successful product company, and I asked, "Why are you interested in this XP stuff?" And he replied, "Actually, we have a waterfall style process, and it works really, really well. It's smooth, we've got it down to a science.... We've got this nine-month cycle, and everything works really great." I say, "Okay." He continues, "You know, we just have it down to a science. We know exactly what we're doing with this waterfall...." At about this time, I'm thinking, "Oh, apparently things aren't very good or you wouldn't have to be telling me over and over just how good things are." I always have to ask those questions, and then I come back to those answers when I meet resistance. Someone says, "You know things are really crappy here, and it just seems like it's time for a change." Or, "We're doing really well, but we're obsessed with making things better." When someone says, "Oh, I can't write tests before I write code," then I have to come back and say, "You know you said you had way too many defects. How about, even if this is impossible, you give it a half hour just to prove that it's impossible." My part in the facilitation process is very much a "hands-on" kind of bodywork. It's more of a "let's get in there, roll up our sleeves, and do some stuff" approach, as opposed to trying to convince a CEO to set up a committee on the testing of code before it's written. I'd rather say, "We have a half hour, let's just go off and do something."

Q: What do you recommend to companies that are interested in getting started with XP?

KB: The obvious place to start is a weekly planning process with scope negotiation like the planning game. I'll say this, and people are going to say, "Geez, don't people do this anyway?" But you write down all the things that you need to do, say how long you think that they're going to take, look at what you did last week and how much you accomplished, and then plan for getting about that much done this week. And, if there's stuff that falls off the end, it falls off the end. But you do that every week, and you make it very visible by writing things on cards and putting them on a big board or something like that. That has an enormous impact on a lot of tough situations. Just the realization that you're not going to be asked to do the impossible anymore is a real relief to people. It's a stress relief. When folks are stressed, they have a really hard time changing. The first thing you have to do is to bring the stress level under control. And then the other thing is, programmers can go off and start writing tests before they write code. You can download simple tools from all over the place. I have something called JUnit that I work on (for more information on JUnit, see http://www.junit.org). It's free, and you can do it in the privacy of your own cubicle and wash your hands afterward; it's just not a big deal.

Some people start with the project room and pair programming. That seems to be common if you have a real junior team. And again, it's not going to cost you a lot of money. The downside -- if it works badly -- is really not so horrible. If you're going to go with a project room, I think that it's very important that you get your work hours under control. Project rooms and long hours are a really explosive combination. As long as morale is good, it can stay good. But if morale drops, and you're in that project room, and people are tired, then it can go really bad, really fast. I recommend to organizations that are going to do project rooms that they make sure that the work hours are under control. They should be under control anyway, just in general. But this is encountered a lot in companies that equate work hours with production and not production with production.

-- Cutter Consortium

-- Kent Beck, Senior Consultant, Cutter Consortium