Software Reality
Extreme Programming

Site Map

XP Central
Case Against... Songs

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:

The Case Against Extreme Programming

XP's Audience

<< Contracts in XP (Release Plan Optimism)

XP is aimed at customers who don't know what they want.

The previous sentence isn't intentionally provocative. The point about XP is that it's an agile methodology. If the customers knew exactly what they wanted, then they wouldn't need a process that focusses on changing the requirements at any stage, or a process which requires putting a huge amount of effort into keeping the product "releasable" at any point, whether it's due for release or not (just in case the customer suddenly decides to cancel development).

If the project is not ailed by vague and "dynamic" (read: fickle) requirements, then XP is probably the wrong process to use. In other words, if the problem domain is well understood, and the requirements are not likely to change, then you should choose a process that places less emphasis on the ability to "chop and change" at any stage.

Conversely, if the requirements are vague or likely to change in the course of the project, it could be argued that XP still isn't the best process to use. There are processes that are much better suited to handling change halfway through a project - providing requirements traceability and impact analysis (including support for quickly providing cost estimates so that the customer can make an informed decision about whether to authorise any changes).

To really get a feel for the impact of any change, you need an architecture (not a heavyweight document, but a high-level overview of your design and system topology). This gives you a roadmap with which you can easily trace out the overall impact of any potential change: "If I change this component, it will affect these other four components that use it. Plus it means that component X, which hasn't been written yet, may take a little longer than was originally estimated. But it covers component Y, which now won't be needed at all..."

With XP, your design only covers what has been written so far. Thus, it is very difficult to look ahead and plan future components.

The website claims:

"In many software environments dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not."

The problem with this approach is that it is very reactive, treating the symptom instead of the illness. They should be educating the customer, attempting to address the reason why the requirements are changing so much.

For example, the customer might simply be unsure about exactly what their business requires. This is where you come in, as a business consultant: you should be presenting the customer with use cases, mock screenshots, prototypes (using quickly knocked-together, throwaway code). This all helps the customer to visualise what they really want, helping them to pin down the requirements before a single line of production code is written.

In XP however, the approach is to defer the hard questions until the last possible moment, and to change the design if needed. XPers believe that development is "frictionless", i.e. change at no cost, no heat, no inertia. However, there is always a cost associated with change.

Of course that doesn't mean that the project requirements cannot change once they have been "signed off" by the customer. These sort of changes should be minimal though, as (taking a non-XP approach) all the really hard thinking would have been done up front, and all the hard questions would have been asked (and answered). The problem domains have been identified; the nastiest problems carefully thought through and resolved.

The trouble with encouraging frequent changes is that it leads to the "just a little bit better" syndrome (even at a subconscious level). In other words, the developers get very excited about an idea they (or the in-house customer) have had, and in chatting about it they become even more excited. In it goes. But the real customer (that reticent, cigar-chewing man back at Customer Towers) might not be quite so appreciative of this shiny new feature.

>> What XP Values the Most


Software Reality XP Forum

<< Back to XP Central

<< Back to the Front Page


All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright 1998-2008 Matt Stephens. ALL RIGHTS RESERVED.