Agile – eXtreme Programming (XP) Methodology Testing

Wildly conflicting requirements is not unusual in the corporate world. And this is frequently the reason for business process automation projects to "fail." It can be as simple as "the policy and procedures manual says to do X" while the people that actually do the work do Y. Making the software do Y means that the people paying for the software will insist that the software is defective from their perspective. Making the software do X means that the people who actually get the work done cannot get the work done.

Normally, most development companies will choose what the managers say over what the workers state because that's how the bills get paid. In the ideal world, there is no impedance mismatch between written and actual policies; in the real world much office work is informally partitioned and undocumented.

Camp A will losely dictate that Feature X works like this, then Camp B will fail it due not functioning like that.

The mismatch between CampA and CampB is a political issue and not a software issue. Solving the problem is going to involve talking to people and getting one clear winner.

XP doesn't explicitly call for the creation of a model, but it doesn't say that one should never be produced. If developing a model helps you to build and then document your system, it should absolutely be done. The difference is that Agile Modeling has a different focus than system modeling in a plan-driven environment. In fact, the Agile Modeling site even addresses specifically how you model in an Extreme environment.

Agile environments take a more Lean (in the same sense of Lean engineering or Lean manufacturing) approach. Some of the key tenants include reducing waste, deciding late, and delivering fast. In order to eliminate waste, only the required documentation is delivered at the appropriate granularity. If you produce a work product, that work product is expected to ultimately add value to the customer - waste is considered anything that doesn't help add value to the person paying for it.

In fact, the XProgramming blog article you linked to supports this:

You may well need some nicely formatted UML for your project...If and when you really need these things, then by all means you should do them. But inside your collocated Whole Team, you most probably will not need them, because the information you need will be communicated through the more effective medium of conversation.

The Martin Fowler article that you linked to also supports this:

Certainly XP de-emphasizes diagrams to a great extent. Although the official position is along the lines of "use them if they are useful", there is a strong subtext of "real XPers don't do diagrams".

A central idea of the agile methods is "individuals and interactions over processes and tools". You don't follow a process or use a tool for the sake of following the process or using a tool. If the task that you are working on does not add value or if it doesn't produce something that is useful to someone (either the customer or another engineer), then you don't do it.

Martin Fowler goes on to say:

The primary value is communication. Effective communication means selecting important things and neglecting the less important. This selectivity is the key to using the UML well. ... A common problem with the common use of diagrams is that people try to make them comprehensive.

Again, same idea. The purpose of any documentation is communication. If you are producing things that don't help you communicate the system, why are you doing it? Don't focus on every little detail, but focus on communicating a message that provides useful, value-adding information to someone else.

Even later in the article, Fowler goes on to note that one of the problems with CASE tools is that they can fall out-of-sync. As soon as the code and the documentation fall out of sync, the document adds no value. I'd even take this a step further and say that it adds negative value, as it provides false and misleading information to anyone who tries to use it to make a decision. If you have a process to maintain synchronization, that's good. However, if you don't and you do let your documents fall out of sync, this brings up another question: why do you have them? They clearly aren't being used, or else they would be maintained.

Rather than some other model-driven methodologies requiring the models, even if they don't necessarily add any value, XP calls for spending time and resources on things that actually help you deliver value to the customer/client. If you can justify that certain models actually do add value to your project, then by all means you should produce them. However, you shouldn't be producing models that duplicate other information or don't add value.