XP AND CULTURE CHANGE

by Kent Beck

Extreme Programming (familiarly called "XP," but not related to that more recent "XP"-labeled product) is a cooperative style of software development. Business and technical folks live in the same project room. Every week the business folks choose new scope, in the form of a set of tests that should run, and the technical folks deliver that scope. When reality diverges from the plan, the plan is changed (which is easy when you plan every week).

I, as a programmer, must work with integrity in order to tolerate such intense interaction with the business:

• I write a failing unit test before adding or changing any code. If I have many changes to make, I write the tests one at a time so later tests can benefit from what I learn. As the ladies of River City might put it, "Test a little, code a little, test a little, code a little, cheep, cheep, cheep, test a lot, code a little more."
  
  
• Whenever the design reality diverges from what the design should be, I bring the design back into alignment before proceeding. The most common expression of this is that I find duplication and have to change the design so I don't repeat myself.
  
  
• After coding and designing like this for, at most, a few hours, I integrate my changes with the latest released code. I run all the tests, both the small-scale tests my programming compadres and I have been writing and the larger-scale tests written by the business side of the team. If, and only if, all tests run, I release a new system.
  
  
• I have a partner sitting with me while I'm writing and integrating. While I have the keyboard, I'm thinking tactically -- what's the next test; how can I make this test work; how can I refine the design? My partner is thinking bigger thoughts -- is this whole approach doomed; where can we make bigger design improvements? When I begin to tire (typically after three to five minutes), the keyboard moves to my partner and we swap hats.
  
  

I, as a business person, also have a difficult job to do:

• I have to break big business thoughts into small increments of functionality that will represent progress toward those goals.
  
  
• Just in advance of implementation, I have to translate these small increments of progress into automated tests that will demonstrate the presence of the features I am requesting. This requires specialized skills to do well, which is why the business side of an Extreme Programming team is the home of folks who formerly did post-development quality assurance.
  
  
• Every week I have to pick what we will work on next out of a pile of work that is always too big.
  
  
• As we gather facts about how fast the team as a whole can make progress, I have to adjust the amount of work to fit reality and communicate the consequences of these plan changes to the rest of the organization.
  
  

On the whole, Extreme Programming shifts responsibility for the scope of the delivered system from technical to business folks. The technical folks, in turn, accept responsibility for the correct functioning of the system and for providing accurate and honest reports of progress.

A culture is the way things are done, seen, and remembered. Because culture embodies perception and action together, changing culture is difficult and prone to backsliding. You change the way you do design (such as, to organic, piecemeal, situated design), but you can't immediately change the way you evaluate design (is the design document done?). Is it easier to change your perception of design or go back to designing the old way?

It is mostly easier to go back to the old way.

So why bother? Well, as reported in a recent Cutter IT Journal issue on XP and culture change, XP projects that are technically successful in the sense of producing more functionality and fewer defects offered greater transparency and control for the sponsors than projects done in the old ways of working.

--Kent Beck, Senior Consultant, Cutter Consortium