I have seen some great work done with activity diagrams and use cases on smallish systems.  However, it has always been my experience that  mixing the UML functional modeling techniques with larger scale efforts spells big-time trouble.  Proper analysis requires postponement of implementation aspects until the appropriate time.   Use cases, by their very nature, are implementation oriented; they force the analyst think of solutions too soon.

Remember, agile does not propose any new modeling techniques, and proper use of modeling is key to success.  Don't let the latest buzz word cause undue confusion.   I would focus on gaining a clear understanding of what the important differences are between functional modeling techniques.  

Tony

Vessela,

I have yet to be part of a formal Agile Project.  Yes, I said formal Agile Project and no that isn't contradictive.  Even an Agile Project should follow a structured and agreed-upon process, even if that process is lightweight with minimal documentation.

I have read a bit on Agile and also heard from some colleagues and friends that have been on Agile Projects.  Most people, with the exception of the hard core Agile promoters will agree that Agile has it's place in the IT systems world, but isn't great for everything.  It often can be useful on small or even medium size projects in some cases.  However, most agree that it is not good for large, complex projects. I'll give an example of why in a bit.

I have also seen a few informal internal projects (the unofficial projects where the Dev team works directly with other teams to put together a feature list for a new tool and then codes it iteratively using short 1-2 weeks intervals for releases and feedback).  It can work well.  But it also has shown me spme major risks of Agile.

Imagine setting out to create a large and complex system, or even a small system that was initially intended to meet only certain needs (requirements) but eventually grows into a more complex system that can handle many more requirements.  If you have not performed enough analysis upfront to identify the majority of the requirements, or if the requirements change on you rapidly you will most likely find yourself with one of the following problems:

1. The system architecture can no longer support the newer requirements because technical design decisions were made based on the initial set of requriements
2. In order to support the new or altered requirements, you need to redesign a major chunk of the intial system (imagine how costly this becomes if it happens a few times)

These are just some things to watch out for.  I'm sure some people have pulled off large scale Agile projects, but they certainly have their risks.

Also, beware of the companies that like to use the latest buzz words.  While you may be using SOME Agile practices, it sounds like your organization is really using more of a hybrid approach.  This may help you overcome some of the inherent risks associated with Agile on large projects.

"Change management does indeed become a form of 'change prevention' in this case, which Agilists can view negatively but in this scenario I view it as necessary and in fact beneficial to the success of the project."

I am so sorry to hear that again. For me "success of a project" is that it provides the right value to the customer. You, like many others, seem to define success of a project as a team delivering what was written in a spec when the client (most probably) didn't know what he wanted.

If you see that the customer is making changes which don't make sense given the business objective, it's valid to try and prevent that change. But "change prevention" just so that you can stick to your plan goes against the basis of the IT industry. IT was born to help business run smoother with the help of technology, wasn't it?