It has been a year since Chris Collins and I wrote "XP distilled," and a good bit has changed since then. Extreme Programming (XP) has grown up some, and more people are implementing it in their organizations than ever before. But even with XP gaining ground and the resultant buzz this has created, there is still a great deal of confusion and debate about what XP is and is not. Not surprisingly, even Microsoft has contributed to the confusion by labeling its latest operating system "Windows XP."
In the coming months, I'll use this column to cut through the hype, misrepresentation, and genuine confusion surrounding XP. I hope to give you a pragmatic resource for answering your questions about XP and an idea of how to implement it in your organization. The first several articles in this column will be an expanded version of "XP distilled" that covers current practices and thinking related to XP. My goal is to provide you with a good foundation to support further exploration of XP and how it can make a difference in your company and your career.
I've been working in the software industry in some capacity for almost ten years. In that time, I've never seen or experienced a software development approach that excites me like XP does. I believe it is a natural way to program -- it just might not feel natural for everybody when they start. But give it a chance to work and you'll wonder how you ever survived using any other approach.
Of course, XP is not the only way to develop great software, but I am convinced of two things:
- The principles XP puts into practice are the right ones.
- I've never experienced an approach to software development that puts all the pieces together like XP.
So, if you haven't sensed it already, I'm unabashedly enthusiastic about XP. In the end, I hope you will be, too -- but not because of clever marketing. I think the best way to convince others is to put XP on display, warts and all, and then let people decide for themselves whether the XP approach is better than the one they're using.
In the year since "XP distilled" was published, the biggest problem facing corporate management -- inside and outside IT -- has not changed: how can leaders exploit their IT assets and capabilities to gain a competitive advantage? In many cases, these "assets and capabilities" we're discussing revolve around software and making software. That's where the trouble starts.
Programmers have been churning out code now for over 50 years. In that time, mountains of code have been written -- some of it good, most of it bad. The reason for this poor average is simple: traditional approaches to software development set projects up for failure. The worst part is that well-meaning, hard-working, brilliant people see a significant number of their projects fail. In "XP distilled," we gave you some numbers on project success. Figure 1 shows some updated numbers as of the 2000 Group CHAOS Report. (Incidentally, my editor asked me if I would mind defining "CHAOS." I responded to him that I wouldn't mind in the least, except that the Standish Group refuses to divulge the acronym's meaning. And -- as I told my editor -- no, I'm not putting you on. You can read a blurb about it in Keeping CHAOS quiet, available in Resources.)
Figure 1. Software project success and failure, then and now
I first saw a graph similar to this one in a software magazine article. The authors titled the graph, "Projects Show Steady Improvement," and they noted that in 1994 only 16 percent of projects succeeded, whereas in 2000 28 percent succeeded. While 28 percent is certainly better than 16 percent, the results are still abysmal. As I said before, if you use standard software development approaches, even if you are developing Java applications, prepare yourself for disappointment. Despite some improvement since the first CHAOS Report in 1994, almost three-fourths of projects still fail. No wonder company leaders are reluctant to spend money on software projects.
Why are these numbers so bad? There are probably as many opinions on that question as there are people asking it, but I think there are a few primary reasons:
- People aren't convinced they have a problem.
- People know they have a problem, but are afraid to risk doing something different to try to solve it.
- People know they have a problem, are willing to try to solve it, but misunderstand the problem they are trying to solve.
- People know they have a problem, are willing to try to solve it, understand the problem, but are constrained to the status quo.
Let's cover each of these reasons briefly.
People have an extraordinary capacity for self-delusion. Company and project leaders are no exception. It's quite possible for software development projects to be going down the corporate drain while everyone is convinced everything is fine -- or at least they act like it is. The numbers I mentioned earlier should make it obvious that software development in organizations isn't going well. There are exceptions, of course, but lots of organizations are oblivious to their own problems.
Does your organization have an adversarial relationship between IT and "business people"? Do business leaders in your organization say things like, "If technology is so slick, how come all I hear from IT is 'No'?" If so, you have a problem that needs solving. If you don't solve it, inertia may keep you going for a while, but failure looms.
More commonly, intelligent and observant people in an organization recognize that their current software development methods aren't working. They simply are afraid to risk trying something different to make the situation better. This is understandable. Trying new things requires courage and often involves taking a risk. And in our culture of quick wins and instant gratification, failure can be harmful -- or even fatal -- to your career.
With the odds stacked against them, most people take the path of least resistance. This approach may preserve a career in the short term, but it only postpones and compounds the problems. If you wait too long, little problems become insurmountable. Ultimately there is no way to force people to be brave and take more risk, but ideas in this column and the associated forum might help you get people in your organization (including yourself) past the fear of failure.
Sometimes people know they have a problem and are willing to try to solve it, even if that means trying new things. But they try to solve the wrong problem. For instance, they try to solve a production problem, assuming (perhaps unconsciously) that developing software is like turning out products on an assembly line. It doesn't make sense to have folks on an assembly line diverge from the efficient order and method of assembly. Software is different because it is an emergent reality. In his presentation from XP2002, Agile Methodologies: Problems, Principles, and Practices, Jim Highsmith describes the difference between optimizing and exploring in software. In software, we're often exploring new territory and doing things that haven't been done before. This makes software development an entirely different sort of problem that requires a different solution.
If you try to "mechanize" or control the software development process too much, you'll lose control. I hope the upcoming articles in this column will help to articulate the software development problems you are trying solve.
Finally, people might know there's a problem, are willing to solve it, understand the problem they're trying to solve, but are unable to act within their organizations. This is a sad and difficult -- but not necessarily impossible -- problem to overcome. Unfortunately, it requires much more courage than most people have. Sometimes you have to step on some toes to cause change. I know that's easier said than done, but if you're part of an organization with leadership that refuses to address problems jeopardizing the organization's health, you have a choice to make: you can go for broke and try to create change, or you can leave before the organization gets crushed under its own weight. This article and future ones in this column should give you some good arguments to help overcome resistance to new things in general -- or to XP in particular -- within your organization.
In a way, the name "Extreme Programming" is unfortunate. Most people probably think of extreme sports -- or a Microsoft operating system -- when they hear about XP. The idea behind the name is that there are best practices for software development, such as writing unit tests and code reviews. Why not do them all the time? When you do, they morph into concepts like test-driven development and pair programming, which most people view as rather extreme. That's where the name came from. It has nothing to do with soda, bungee jumping, or Bill Gates.
Perhaps as a defense against misplaced and myopic criticism of the name, people who think approaches like XP are good have begun calling such methods agile. You'll hear talk of Crystal Methods, Adaptive Software Development, and (currently the most popular) XP as agile methods. All of these processes embrace the reality that people work with people to develop software. Successful software processes must maximize people's strengths and minimize their weaknesses. In my opinion, XP does the best job of addressing all the complementary forces that affect the people involved, and of helping the programmers on the team to do the right thing when they write code. It also lets them write code most of the time, which is what they like to do anyway.
Whether you call your approach agile or something else doesn't matter -- results do. The goal is to balance all the forces to develop software intelligently. In my opinion, this approach requires brutal honesty all the time. It requires radical commitment so you don't buckle under the constant pressure to quit and do things the old way. It also takes skill.
Contrary to what most people say, I do not think every programmer can flourish on an XP team. The XP approach requires too much constant honesty and humility. Programmers tend not to learn that in school, and most corporate environments don't reward it. Humans develop software. We all have weaknesses, and we share many of them. We need an approach that lets people be people, and makes it very difficult for them to behave badly. I believe XP does that better than any other approach I've ever seen.
As we said in "XP distilled," XP prescribes a core set of values and practices that allow software developers to do what they do best: write code. XP eliminates the unnecessary artifacts of most heavyweight processes that distract from that goal by slowing down and draining the development staff (such as Gantt charts, status reports, multi-volume requirements documents, and so on). Kent Beck outlined the core values of XP in his book, Extreme Programming Explained: Embrace Change (see Resources). These values haven't really changed in the last year. I still summarize them this way:
- Communication: Problems with projects often can be traced back to somebody not talking to somebody else about something important at some point. XP makes it almost impossible not to communicate.
- Simplicity: XP proposes that you always do the simplest thing that could possibly work with regard to process and writing code. The way Kent puts it, "XP is making a bet. It is betting that it is better to do a simple thing today . . . than to do a more complicated thing today that may never be used anyway."
- Feedback: Concrete feedback early and often from the customer, from the team, and from real end users gives you more opportunity to "steer" your efforts. Feedback keeps you on the road and out of the ditch.
- Courage: Courage exists within the context of the other three values. They all support each other. It takes courage to trust that concrete feedback along the way is better than trying to know everything up front. It takes courage to talk to others on the team when that might expose some of your own ignorance. It takes courage to keep the system simple, deferring tomorrow's decisions until tomorrow. And without a simple system, constant communication to spread knowledge, and feedback to steer with, it's tough to be brave.
In a paper I co-authored for the XP2001 conference in Sardinia, Italy, I suggested that introspection be added to this list. I realized when I was presenting the paper there, though, that introspection was really more of a practice. The strong candidate for inclusion as another value is based on a paper by Joshua Kerievsky (see Resources). In it he talks about how continuous learning is a requirement for a healthy XP team. I agree. I don't know what kind of support there would be among XP practitioners for adding another value, but I think it makes good sense.
When I first read Extreme Programming Explained, I was so excited I could barely put it down. I was struck by the huge contrast between software development in most corporate environments I had seen and the refreshingly honest approach Kent was describing. But I had a sneaking suspicion that the book left a little bit too much to the imagination on the business side of projects, which would cause some problems with acceptance. I was struck by an overwhelming sense that XP is about much more than programming.
Fortunately, there has been significant talk in the XP community, Internet newsgroups, and other forums about the "12 practices" of XP. People are recognizing that the first release of XP, so to speak, seemed to emphasize the programming aspects of software development to the detriment of other things, and that the business side wasn't quite as complete as it needed to be. The foundational principles are good, but there are some more practices that need to be included to complete the picture. Implicit in the revised practices list (which contains 19 practices instead of 12) is the recognition that XP is, in fact, about more than programming. It is about creating the kind of organizational change necessary to produce great software. This approach requires impressive coding discipline and skill, certainly, but it also requires significant changes in the way everybody on the team thinks about creating software. This means everyone on the team, including users, business analysts, and strategists. The new practices make this absolutely clear and focuses on creating one team to produce great software in perpetuity. In fact, this emphasis on one team is the primary driver behind the changes taking place in the XP world. In a draft of a paper on the subject entitled One Team, Kent Beck said:
The biggest error in Extreme Programming Explained is the implicit assumption that you have a technical team serving a single customer.
Later in the same paper he said:
The problem is compounded in XP Explained (and subsequent writings and conversations) by referring to the programmers when using the phrase "the team," as in "the customer speaks to the team with one voice." This usage always bothered me, but I didn't know what to do about it.
The new practices and the focus on one team try to address that concern. Any approach that aims to bring about organizational change in software development must heal the rift between IT and business. One of the biggest reasons there is a rift in the first place is that people involved in creating software haven't been part of the same team. So what is this one team supposed to look like? In the same paper, Kent uses a three-legged stool analogy. The programmer team is the programmers, while the business (or customer) team is the analysts, users, testers, and so on. The third leg is the management team, which is made up of people who answer such questions as:
- How does the project get started?
- How is investment increased, reduced, or terminated?
- How are disagreements resolved that aren't handled by business and development?
- How are relative priorities set between this team and all the other projects that need to be completed?
So now we have our one team defined as three subteams: programmers, customers, and management.
While the management team makes some of the big business decisions, there isn't a single team in charge of the development effort. Everybody is on a single team, with different people playing different roles. Of course, this can be easier to say than do. It requires a good number of people to be willing to do things differently. There is a risk of failure (and possibly termination), but the payoff can be grand.
Great. We have one team. What does everybody do? Just like a year ago, all of the XP practices translate the four values into the things you should do every day as a member of a software development team, whether you're technical or not. There isn't much new here for people in either role. The XP programming practices have been recognized by the industry for years as best practices, and the more business-focused practices are recognized as effective (see the Standish Group CHAOS Report in Resources for evidence). It is still true that the word "Extreme" in Extreme Programming comes from two things:
- XP takes proven industry best practices and turns the knobs up to 10.
- XP combines those practices in a way that produces something greater than the sum of the parts.
If everybody is on the same team, the second point can become amazing. But as soon as you cut off one leg of the stool, prepare to meet the floor. XP has never guaranteed -- and never will guarantee -- that people will do the right thing all the time, but it allows them the opportunity to try. This goes for all members of the team, technical or not. People on one team using all of the practices working together can produce significant increases in speed and efficiency. These practices can create an environment that allows an organization to produce great software. Should there be any other kind?
The 19 practices of XP (see Table 1) define the habits various members of the team should have. This month, we'll take a closer look at the joint practices, since they bind all of the members of our one team together. Next month, we'll look at the programmer practices, which formed the bulk of the original 12 XP practices. The month after that, we'll cover the customer and management practices. This will give you a better understanding of what it means to develop software with XP.
Table 1. The 19 practices of XP
Before we discuss the joint practices, let me be clear about what the practices are and are not. The practices are not XP. XP is more than that. In fact, the XP values aren't XP either. Ken Auer, Erik Meade, and Gareth Reeves wrote a paper called "The Rules of XP" (see Resources), which described this well. In a nutshell, they said:
XP's values make it agile. XP's practices do not define XP . . . XP is defined by its rules.
Using Alistair Cockburn's game analogy, they go on to describe the "Rules of Engagement," which dictate the environment in which software development can take place effectively. They then discuss the "Rules of Play," which define the minute-by-minute activities and rules within the framework of the Rules of Engagement. They suggest that:
- The Rules of Play are what make XP unique.
- Following the Rules of Play is Extreme Programming.
- Following the Rules of Play and the Rules of Engagement is Extreme Software Development.
The XP practices are important because they reinforce behavior that increases the chances of a team producing great software for as long as people on the team want. But XP is more than that. It extends beyond programming to encompass the entire software development process. The revised XP practices take this into account by requiring different behavior from everyone involved.
It is becoming increasingly clear that there are four categories of XP practices. There is a set for each team within the one team, and there is a set that brings those three sub-teams together. Most of the original 12 practices are in the programmer team set, but some will probably be moving. Some names have changed, mostly because the original names either weren't as good as they could have been or didn't really make as much sense as they should. Some practices weren't in the original list of 12. In the next section (and in future articles), after each name, I'll parenthetically note whether the practice is new, is unchanged, or maps to an original name. Note that these names are in flux, but the principles probably aren't.
Before describing the practices, it's important to address what I would call the "piecemeal argument": does a team have to use all of the practices, or can it just pick the ones it likes? XP as a discipline assumes a team is using all of the practices all of the time, but a team can pick a few practices and use them successfully (such as refactoring or pair programming). You are free to do that on your team. I would choose not to do that on my teams, because I believe the practices are mutually reinforcing and work together so well that I give up something amazing if I leave one or more out. But that decision is up to you. If you want to try XP, I recommend you use all of the practices all of the time for a while, to see which ones you would be willing to give up. I'll bet the list will be small.
Okay, on to the practices. I'll talk about the joint practices this month to set the stage for all the others. First we need to make sure we have a single team using all of the practices together. This is a prerequisite.
This group of practices is for everyone. Everybody on the team (programmers, customers, and management) needs to be doing these all the time. They bring the sub-teams together to create the one team we're after.
The original metaphor practice was a dud. The idea wasn't bad: to have a controlling image that describes the system in terms everyone can understand and gives it a unifying theme that allows the team to know where new things fit. The problem was that the practice really distracted from the main goal: a shared understanding of the system. Everybody on the team needs it. Sometimes a great metaphor isn't available, or would take lots of time to figure out. Don't delay simply because you don't have a nice word picture of the system you're trying to build. Focus on having a shared vocabulary (what Ward Cunningham calls a "System of Names") that everyone can use. If a metaphor helps, use one. If you can't find a good metaphor, just agree on the shared vocabulary (which shows up in names for classes, methods, and so on).
In Extreme Programming Explored (see Resources), Bill Wake talks about metaphor as well. He says:
Determine the metaphor during the exploration phase, when stories are written and spiked. Revise it as you go. Let the metaphor guide your solution. Use its names for the uppermost classes. Understand how those classes interact.
He suggests using the "naive metaphor" (that is, let objects be themselves) when you can't think of a better one. Good advice.
Informal communication is more effective than formal most of the time. Cubicle walls make informal communication more difficult. The best solution is an open workspace where people can overhear things, contribute when it makes sense, and have impromptu discussions about anything that matters. This kind of group interaction can create amazing emergent results. I've seen it in action. Tear down the walls. Your team will be better for it. If your organization can't stand to have some furniture moved, you have a bigger problem.
A typical reaction to the open workspace practice is skepticism that a bunch of people talking in the same area would distract each other. Speaking from experience, that does happen. An open workspace works well when the people on the team respect each other enough to work in that workspace, rather than goofing off. If someone wants to goof off, they go to the goof-off area, which should be a different place. This doesn't mean the workspace can't be fun. It should be fun, but it also should be a place where work gets done. If the members of a team care about each other and care about the work they're doing, they can make the open workspace work. You should assume it won't be a problem and only handle it if it becomes one.
I've heard some people suggest that the open workspace practice means XP will not work for large teams. They suggest that a large number of people in a single mega-cube (or some other open workspace) would be chaotic. Maybe they're right. I think that's the wrong emphasis, frankly. They seem to be assuming two things: that you need a large team and that there isn't a collaborative environment that will support one.
Perhaps you need a large team. But did you really think about it, or did you just grow? Perhaps a small group of good developers working in an environment conducive to doing great things -- with the support they need -- can do more, better and faster than a larger team. Maybe not, but it's worth considering.
Suppose you do need a large team. How could you create a collaborative environment for it without creating utter chaos? What if you had multiple adjacent open workspaces with semi-permeable barriers (an open doorway, a half-wall, an aisle between mega-cubes, and so on)? I believe most people who say you can't create a collaborative environment to support a large team aren't too fond of the idea generally -- small team or large. It's a mistake to assume that an open workspace precludes a large team.
People who use XP often talk about the "rhythm" of a project. This rhythm exists at different levels, but the iteration is the real heartbeat. Every one to three weeks the team delivers a working system with new features the customer requested. That's a radical idea. People are not used to creating software this way. Most approaches focus on doing lots of stuff before you write code. XP requires that you write code, let people use it, and let their feedback steer the project (we'll discuss this concept more in a future article).
Each iteration begins with some planning. I (and lots of other people) call this iteration planning, and we do it in an iteration planning meeting. The planning that goes on in this meeting looks a lot like release planning (again, we'll discuss this concept in more detail in a future article), but at a more detailed level. We're concerned only with the next iteration. We ask the customers, "If the project were to end after the next iteration, what features would you want to have?" Then we estimate the work to build those features. We fit what we can in the iteration and defer the rest. Customers drive the priority; the programmers specify the cost. That means some things have to fall off the plate for the current iteration. You can't compromise on this. You can't make more time.
A word about timeboxing is important here. Timeboxing is the practice of setting a time limit for some bit of work, working until the time's up, and then assessing where you are. It is a technique for preventing the team from working too long on tasks, to the exclusion of other things that need to be done. The iterations practice is about more than timeboxing. The iterations practice is really about requiring people to make tough decisions that they are most qualified to make. Customers make decisions about which features are most important to build next. Programmers make the technical decisions about how to build features and how much effort that will take. Management makes decisions about strategic direction for the project and how it needs to fit into the rest of the organizational picture. Everybody on the project team is involved, but they stick to what they know. They use their brains, of course, but they also trust others to use theirs.
There has been some discussion about what to call this practice. Should we call it short iterations to emphasize the shortness of the iterations, or iteration planning to emphasize the community aspect of bringing everybody together to plan? I favor short iterations because it emphasizes the need to get real, working software in users' hands to get concrete feedback.
It's been a rare project in my career where everybody on the team took a little time to look back and identify openly what really stunk. I've had to do that myself. When I did (if I had time), I usually discovered that the problems with a project usually could have been solved before they became problems if the team had spent just a little time addressing them. That's what retrospectives (a term coined by Norm Kerth) are about.
Working without reflecting on what you're doing locks you into repeating your failures. It would be better for each person on the team to reflect on his own actions and on what he's learned, then share that with the rest of the team. As I outlined with Chris Collins in our XP2001 paper Adaptation: XP Style, the individual behavior I'm talking about is introspection. You make your introspection public in a retrospective.
Think about lessons you've learned on the project. Think about what you did well and what you screwed up. Think about how the team functioned. Think about what the team produced collectively. Could things have been better? Why? More importantly, how? What things did you do well that you want to make sure you keep doing? How? This kind of collective review should happen in an organized way at least after every release, preferably after every iteration. It doesn't have to take long. Reserve the first hour or two of your iteration planning session for a retrospective on the previous iteration. Perhaps reserve a day (or more) for a post-release retrospective. Don't pull any punches. You're trying to make your team better here, trying to increase the value you can add to the organization, trying to make your own life better by putting the fun back into work. This is vital.
Most of my colleagues and I have found it helps for each pair on the team to have a "mini-retrospective" at the end of each day. Just a few minutes to reflect. If we learned something worth sharing, we mention it in the team meeting the next day. We've learned a lot this way.
Retrospectives certainly require some vulnerability to be effective. The compensation is a more integrated team. Everybody needs to take part in the retrospective, both the technical and non-technical people. If this would require too many people to meet in one place (and it might), subteams (such as management) could have their own retrospectives and send a delegate to a smaller meeting. The point is to learn so we reduce our chances of making the same mistakes over and over again. This is one team and everybody needs to be fully invested in it.
Ultimately, XP is about organizational change -- it simply starts with software. Putting everybody on the same team, but giving them different jobs, is the best way I can imagine to create change that works. This month we looked at the joint practices of XP that help create the one team we need in order to create that kind of real, lasting organizational change.
As I'll say in closing every time for the next few months, it's important to reiterate that the revised practices I've described here are not necessarily what the "new" XP will look like. I imagine we'll all have to wait for the second edition of Kent Beck's Extreme Programming Explained: Embrace Change to find out what the next release looks like.
Translating what the business wants into software it will actually use is one of the rockiest problems in the world of IT. Getting technical people and business people to communicate consistently and well is a daunting challenge. Most companies behave as if they do not really value communication, despite the lip service they pay to it. They put barriers in the way. Information doesn't flow. Turf wars distract from what needs to be done. People are in the dark about what other groups are doing. Projects take forever to get started, they plod along for what seems like forever, and many times they die on the vine.
This environment probably has been that way for as long as people can remember. Behavior has turned to habit. Business people have grown accustomed to having technical people tell them "no" in a variety of ways, so they approach new projects by throwing in every possible feature request and calling everything high-priority, even when it isn't. Technical people have played this game before. They know the business people don't really need all of those features. Secretly, they believe most business people are stupid and indecisive. They know business people are going to try to change requirements -- probably late in the game -- and they know this "scope creep" will cripple their ability to deliver anything close to what the business wants on time and on budget. So they approach new projects by trying to limit scope, and they run projects by limiting scope creep. This scenario means:
- Business people think the only word IT knows is "no," and they don't get the software they want.
- Technical people feel abused, and they don't get to produce the software they wish they could.
This game is a problem, but it's also a symptom. The root cause is human nature.The real reason technical people don't communicate with business people is because they often don't want to solve business problems. They'd rather play with cool toys and, in the case of technical management, win the power struggle. This isn't universally true, of course, but it's common.
The real reason business people don't communicate is because they don't want to put forth the extra effort to help the technical people do the right thing, and they don't want to be held responsible for project results. If business people want technical people to understand what they really need and why, they first need to understand it themselves. Often they don't. If business people want technical people to produce the "right" software, they need to spend time with the technical people to help that happen. Often they're unwilling (or not allowed) to do that. Most business people don't see that as part of their jobs.
This kind of contention makes the lackluster results of most software projects look less surprising. In fact, I'm surprised that any projects in environments where people act this way actually succeed. So how do we fix this? Nothing short of organizational overhaul is required. Incremental change probably won't cut it, although I'm willing to help organizations try to change that way. The primary catalyst for this change is a radically different way of developing software that requires and enables cooperation between business and technical members of the software development team. I think that's what XP is.
Recall the one team concept I talked about earlier. If you're a technical person, do you typically think of business people as being on your team? If you're a business person, do you think of yourself as being on the software development team? To produce radical change in the way we make software, we have to change how people relate to one another. XP requires this, and the customer practices described in a future article of this column will make this abundantly clear. Customers need to drive the process from start to finish. As a programmer, those customers are on my team. We are in this together. Likewise, business people need to be willing to drive. They need to make the tough business decisions about which features are in or out. They need to be able to release early and often, even when the system isn't "finished," so the team can get concrete feedback from real users. They need to specify when a particular story is "done," in the form of a customer test. That's radical.
XP is about much more than programming. It is about radical, life-changing, organizational change. I believe that's the only cure for the illness that infests corporate IT.
This month's column gave you an overview of the joint practices of XP that can help you create one team, rather than squabbling groups. Next month I'll cover practices for programmers. Those practices tell programmers what to do every day to create the system your one team wants. Does pair programming sound strange, or even silly? Does continuous integration sound impossible? Next month you'll learn what they mean, and that they're not as crazy as you might think.
- Participate in the discussion forum.
- Read all of the articles in the Demystifying Extreme Programming series.
- Read the original "XP distilled" (developerWorks, March 2001).
- JUnit.org is a tremendous resource for this popular testing framework developed by Erich Gamma and Kent Beck.
- Visit Xprogramming.com for the scoop on Extreme Programming.
- If you want to learn more about XP, be sure to pick up a copy of the books referenced in this article:
- Extreme Programming Explored by William C. Wake
- Extreme Programming Applied: Playing to Win by Ken Auer and Roy Miller
- Planning Extreme Programming by Kent Beck and Martin Fowler
- Extreme Programming Explained: Embrace Change by Kent Beck
- Find hundreds of Java technology related resources in the developerWorksJava technology zone.
Roy W. Miller has been a software developer and technology consultant for almost ten years, first with Andersen Consulting (now Accenture) and currently with RoleModel Software, Inc. in North Carolina. He has used heavyweight methods and agile ones, including XP. He is co-author of the Addison-Wesley XP Series book, Extreme Programming Applied: Playing to Win, and is currently writing a book about complexity, emergence, and software development. Contact Roy at email@example.com or at firstname.lastname@example.org. You can visit his personal Web site at www.roywmiller.com.