I have been working on a project with a very complex domain for the last year and a half.  Our team has been doing our best to make use of agile principles, but I am seeing a few places where Agile breaks down.  The greatest challenge for our project is that the stakeholders do not have a complete or clear understanding of the domain.  This isn’t necessarily their fault, as we are replacing an old main frame government system based on 30 years of convoluted and conflicting legislation.  Within those realities agile makes a few implied assumptions that limits its usefulness on our project:

1) That a clear understanding of the domain exists somewhere, and you must work closely with those individuals to extract that information.

2) That there is something for the stakeholders / users to interact with as the project iterates (i.e. a user interface).

In addition to the ongoing new domain revelations that we seem to continually be discovering along with our stakeholders, the guts of the application we are building computes complex tax calculations that run in a batch process like fashion, using attributes across seemingly countless domain objects.  This means that often the only artifacts to deliver to the stakeholders at the end of an iteration are reports – reports that have to be near complete in order for the stakeholders to make sense of them and be able to compare with the previous systems results (main frame / Excel).  This makes it extremely difficult to quickly iterate and get the necessary feedback to finalize the systems most difficult features.

The reality is that there isn’t a methodology that can fully address issue number one, but it is important to realize that there are issues that methodology cannot solve.  Another example of this, is expecting Agile to compensate or gloss over poor performers.  This is a common one and of course never works, and it only serves to set the methodology up for the blame when things fail. 

For our project, it is important that we iterate in hopes of getting feedback as early as possible, but that doesn’t necessarily mean that our stakeholders ongoing ‘new discoveries’ will come any earlier in the process.  I do like Agile and think it can solve a number of problems, but I often feel that it is over emphasized.  It is just one part of a software project.  To really succeed in building quality software highly competent people are required – methodology should only be enhancing their efforts.  I hope that is a fairly common thought.  I guess the new realization for me personally is that you also need highly informed (in both the domain and methodology) and motivated stakeholders too…