Check Your Premise

One of the primary goals of XP is to make software development rewarding for every person involved in the process, and like the rest of the process, taking that goal to the extreme. Take a gander at this article entitled the XP Bill of Rights. Darrel Norton pretty much buys the whole thing, except for the statement:

“The customer has the right to change his/her mind without paying exorbitant costs.”

Darell’s response:

“So, if the customer were to change their mind after 6 months of building a web application that they really wanted a windows client application, they should not pay exorbitant costs? The statement is comical in its naivety.”

At first glance, Darell might seem to be dead on: If the customer changes his mind half-way through, then this really would screw the proverbial XP pooch. In fact, it would screw any project methodology. But the truth is that XP would prevent a scenario like this from ever happening in the first place. Imagine for a moment that a project team is building some software with YoyoDyne using XP as their development process. The team, including the YoyoDyne representative John, decides that a web application is in order to satisfy the stories required by the client. The build the web application and release it to the users in three weeks. Within a week of the release, the team begins receiving feedback from the users, primarily focusing around the web-based nature of the program: It isn’t responsive, it doesn’t do the complex validation necessary, and the training is too hard because the program is too different from the rest of the client-server software they use. The team decides that the system really should have been a Windows application, and they immediately shift gears.

Sure, the team has now wasted three to four weeks of development time because they made a big mistake. But that’s a huge savings compared to other, less agile methodologies. The users wouldn’t have seen the system for months using most other methodologies. And this contrived scenario is pretty worst-case, too, since most teams have intelligent people who would rarely make a blunder so large. (Although I hvae seen it happen, but not on an XP team.)

The XP Bill of Rights can make its seemingly insane promise because the process is designed so that change won’t be large and expensive. It does this by utilizing short iterations to obtain immediate feedback, and coupling that feedback with the clean-code produced by emphasis on refactoring techniques. This is what it was created for! So it only looks naive if you’re still thinking non-agile.

And if there is a full moon, and the customer really is insane and just randomly changes direction for no reason, then you have bigger fish to fry. Perhaps you shouldn’t be doing business with crazy people.