Let's try to get a sense of what is good process and what is not, without a lot of rigmarole about the specific practices.

A guy walks up to Steven Spielberg and says “How do I become a movie director?”

Spielberg says “To be a movie director all you have to do is say you are one”.

“That’s all I have to do?”

“Yeah. Now if you want to be a good movie director….”

So far being an XP project has been a lot like being a movie director, but how do we make sure our projects turn out closer to “Schindler’s List” than “Plan 9 from Outer Space”? Clearly, there is some difference between saying you are Extreme and really being Extreme.

A lot of emphasis is being placed on the twelve practices, but is that the key to knowing if your project is really doing XP?

The Twelve Practices

XP is most often characterized by 12 practices:

  • Planning Game
  • Small Releases
  • Metaphor
  • Simple Design
  • Testing
  • Continuous Integration
  • Pair Programming
  • Collective Ownership
  • Refactoring
  • 40-Hour Week
  • On-Site Customer
  • Coding Standards

Should we evaluate a project’s XPness by its adherence to these practices?

Is a project Extreme if it follows all 12? Is it Extreme if it follows a specified 5 practices and any 4 of the other 7? If this is true, what are the 5, how do we measure adherence?

Can you pick and choose and still be on the path to Extreme?

Would the answers to these questions help us know if a project is XP?

No, the twelve practices are intended to be a starting point. Projects who want to know how to start XP are pointed to the twelve practices and told to do them for a couple of iterations and then to modify and adapt them to their local circumstances.

So, if the directions on the label say you should change how you use the practices, they cannot be the standard against which to decide if a project is Extreme.

If following the 12 practices isn’t the necessary and sufficient condition, how can we tell if the project we are looking at, or working on, should be characterized as an Extreme Programming project?

First Principles

Kent Beck envisioned a new software development process based on 4 values:

image

  • Communication
  • Feedback
  • Simplicity
  • Courage

That process became Extreme Programming and those values are where we should look when judging a project’s status as Extreme. Communication, Feedback, and Simplicity work together to instill the programmers, customers, and management with Courage. As we see in figure 1, courage is the goal of XP. Courage to change the code when it needs to be changed. Courage to ask for new features. And, courage to believe the results of the planning game.

Courage is the trademark of Extreme Programming. It is our goal. And, it is the yardstick we should use to judge a project.

Courage (and the Lack of It) In Practice

A team’s courage is revealed in how it responds to stress. If every project went according to how it was originally envisioned, the team would not need courage, it would not need XP. XP was designed to allow a team to absorb unexpected changes, to use the new inputs in its next planning session and inform the world of the impact. Non-XP teams quite often react to new inputs by either ignoring them or by believing that the new information will have an insignificant impact on the previously made plan.

It has been my experience that teams that truly follow all 12 practices will have courage. But, I have been in situations when we thought we were doing a good job only to discover that we lacked the required courage to do the job correctly. Usually the lack of courage can be traced to a failure to follow one or more of the 12 practices. That is where we should look to regain our courage, but courage should be our goal and the practices our means for achieving it.

Our goal is to have courage that is based upon an understanding of the state of our project our teams ability to continue to deliver value. A team who does not have this information can still have courage. But, that courage is built on ignorance. Both Custer and Sitting Bull had courage. Sitting Bull also had repeating rifles and a whole lot more men. His courage was well founded. This is why XP places so much emphasis on communication and feedback. It is only through knowing where you are and how well you are performing that your courage will not end up being merely foolhardiness.

A team I once worked on was nearing the end of the second phase of an enterprise altering piece of software. Several months before we had successfully launched the first phase and then immediately started the second phase which was to increase the scope of the software in several directions. As we approached our projected launch date, the customers began adding new requirements, often canceling them after the programmers had them nearly completed. While each of the new requirements would have improved the product, in retrospect, I see that the customers were driven more by fear than by a desire to have a more complete program. The first phase had completely changed how a small group within the department did its work. The customers feared that they would not be able to adapt their work force to the new way of working that the new software would require. We should have recognized their fear and addressed it. We should have improved the feedback loop by having more and smaller releases, we most certainly should have introduced their concerns into the planning game. But the outcome was that the second phase was never launched, and even though we were delivering new features every three weeks and writing one hundred new unit tests a month, and pair programming everyday, and following every other practice, we were not XP.

Fear is the Mind Killer

The lack of courage – what I like to call “fear” – is self perpetuating and can most often be traced to an initial lack of one or more of the other three values. A group of progammers who fear doing the simplest thing that could possibly work because they do not have adequate acceptance testing (a lack of feedback) may later lack the courage to optimize performace due to the systems complexity. Fear will prevent you from doing the right thing, it reduces your degrees of freedom and will eventually drag your project to a halt. This is the antithesis of Extreme Programming.

Conclusion

Delineating the twelve practices has made it much easier for teams to start doing XP on their own. We should remember that the practices are merely the suggested route and that you need to focus on the values behind XP. Simplicity, communication, feedback, and most importantly courage. Over time we will find new practices and new combinations of the original practices that make sense in a particular situation. The practices will change, the values will not.

Even though we are doing most or all of the practices, we need to pay attention to our courage level to know if we are an Extreme project. How do we react when it is suggested to change from monthly iterations to two weeks? Do we approach a performance problem with a patchwork of solutions or do we find the best solution and implement it everywhere it is needed? Do we address the fear in ourselves and our customers that may stop us from doing the right thing? That is what an XP team would do.