Thanks as ever for your comments.

Some of the books I've read on the subject do mention that house building is a bad analogy for agile development but I couldn't think of a more suitable one. The whole point of an analogy is to find a common point subject that most people can relate to and to utilise it to aid communication. An ORM layer for communication?:unsure:

I am currently working on a project on which I have preached the agile gospel. The business people, the PMs, the programmers, the delivery managers and support staff all sat around a table having a face to face discussion and made a rapid choice in favour of a small, light weight project that would be designed to be extendable. There were quite a few points and counter-points made but the face-to-face element really worked.

My role is now as a DBA as I have chosen to be a specialist in a particular area. Regardless of whether I were a DBA or not I would say it would be blindingly obvious that a data driven project is going to require a good database foundation.

If you were talking about a project to harvest information from a web site and store it then I would say that the database layer would be of lesser importance than the harvesting part of the project.

The one thing that the DBA role encourages is not to test the depth of the water with both feet!

The move to agile development is a paradigm shift but having spoken with experience XP protagonists (backed up my own reading) you have to buy into it whole heartedly, you can't really cherry pick bits here and there or the whole deck of cards comes down. My personal opinion is that agile development suits object orientated programming, I believe it originated in the JAVA camp. Even for object orientated programmers I believe some of the techniques came as a shock. i.e. inheritance is bad, association is good. Objects should be open for extension but closed for change etc.

As a final point one XPer pointed out that there are two sorts of itteration. If you see the deliverable as a drawing of a man then one draws an outline of the man on the first itteration and subsequent itterations add more and more detail until you get the finished drawing.

The 2nd approach draws a part of the man in entirety and each subsequent itteration adds a new body part.

If you subscribe to this site then you have almost certainly had to deal with a database that was put in place with the "it doesn't matter now, we'll fix it later" attitude. There are 1001 reasons why it won't be fixed later the least of which are the technical hurdles. I am currently liaising with 3 different triametrically opposed groups of people to get them to agree to do the investigation work to find out what the effects getting rid of a small amount of data that prevents DRI being added would have on their systems.

To the business this is a non-issue as it has zero visiblity. To the DBAs keeping the database functioning is a mind-numbing and time consuming job. Had DRI been put in place in the first place the DBAs could be building the better mousetrap and devoting more time to the developers rather than acting as a bottleneck while they fix legacy problems.