Subject: Extreme Programming- An Interview with Kent Beck, 9/3/02 Date: 3/9/02 10:02 PM Received: 8/9/02 8:08 AM From:

theedge@cutter.com To: edge-list@cutter.com 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 fail ure. In the XP world, providing information that allows you to constantly make that d ecision after four or eight weeks (out of a nine-month development cycle) is wha t 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 manifes t themselves in really bizarre ways; like when I hear, "No, we can't make a proj ect room. We can't remove cubicle walls and have a project room where everyone sits togeth er for most of the day." Now, the laws of physics aren't what make that difficul t. 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 tech nical people. Like, "The business people don't want to sit next to the programmers." As a prog rammer, that's how I would see it. Or "We can't have the salespeople here because they make too much noise." Howeve r, 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 sa les 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 t heir little caves and not have much accountability. They have a big problem with weekly planning, very visible estimation, programmi ng with other people, testing and integration, and being a continuous part of th e 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, "Oka y." 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 t elling me over and over just how good things are." I always have to ask those qu estions, 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 mak ing things better." When someone says, "Oh, I can't write tests before I write c ode," 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 tha t 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" appr oach, as opposed to trying to convince a CEO to set up a committee on the testin g 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 wit h XP? KB: The obvious place to start is a weekly planning process with scope negotiati on 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 t hat they're going to take, look at what you did last week and how much you accom plished, 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 ca rds 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 anym ore 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 befo re 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 ha nds 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 s ure 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 productio n and not production with production. -- Cutter Consortium -- Kent Beck, Senior Consultant, Cutter Consortium http://w ww.cutter.com/consultants/beckk.html

[For more information on Cutter Consortium's Agile Project Management Advisory S ervice, please contact Dennis Crowley at +1 781 641 5125 or e-mail dcrowley@cutt er.com or visit http://www.cutter.com/advisory/project.html .] +++++++++++++++++ ++++++++++++++++++ Extreme Programming really is a simple discipline that can pr ovide valuable and satisfying software results. However, it requires an organization-wide commitment, usually supported by study , training, and practice. In the latest Cutter IT Journal Special Issue titled *XP and Culture Change*, Gu est Editor Kent Beck offers incisive, thoughtful commentary on six instances whe re IT professionals tried to change the way things were done, seen, and remember ed in order to facilitate the XP methodology. Beck analyzes the dynamic culture shifts - some for the better and some for the worse - that occur when XP is introduced in an organization. If you are trying to implement XP in a project in your organization or are think ing about doing so, the honest and provocative information in *XP and Culture Ch ange* will help you see the challenge more clearly and with greater confidence.