Being assigned to a full-blown Agile based development project late in my software application development career, helped me make the decision to finally end my career in software development. I've been in the field for some 30+ years. With the company attempting to move to Agile, I was assigned to one of the first-wave projects.  Contracting with experienced outside Agile developers, I found the whole process a bit overbearing. Daily stand-up status meetings. Constantly in a room with people representing various projects inputs (e.g., business, analysts, testers, developers, etc). After being on it for a short while I thought maybe a younger person would have been better suited for this 'experience'. They might adapt easier and also have a better attitude to adapt as their job will depend on it. I being later in my career and already having thoughts of the big -R (i.e., retirement), this experience just made my decision occur earlier than I had planned. I did give it a good try though and stuck with it for just under a year. I guess I have mixed feelings about the whole concept. Some aspects are good. Some are bad. A lot depends on the type of person also. Extroverts and 'showboaters' I think will do well under this type of environment. Those on the more introverted side might find this environment intimidating. And I am really not sure whether it truly will speed up and improve the quality of the development cycle. I guess each development house will just determine that over time with acquired experience in the process.      

Unfortunately, long-term waterfall projects just don't cut it any more.  By the time you're done (are you ever "done???"), if you didn't allow scope creep, then what you've produced probably isn't relevant anymore! 
 
I've always lobbied for more, smaller, implementations preferring to deliver the most requested features as soon as possible to the end-user, but it's not always possible like when you're completely redesigning an interface.
 
Of course, I can't help but laugh at trying this with the Defense Contractor I worked at back in the early 80's.  To make a code change you had to:
 
1) Checkout the printed code from the facility librarian,
2) Mark the code up in red ink,
3) Make SEVEN (yes, 7!) copies to distribute for comment,
4) Attempt to incorporate all feedback with more red ink,
5) Perform steps 3 & 4 until there were no more comments,
6) Actually code & test (with any major changes going through steps 3 & 4 again),
7) Send the code to the testing department,
8) Send the code to the CMQA Tech. Lead (me) to see if it plays well with the rest of the system,
9) Send the code to the Architecture Group for actual installation and, finally,
10) Check in a printout of the final code to the facility librarian.
 
You wouldn't believe how long even a one line change took!

craigb
Unfortunately, long-term waterfall projects just don't cut it any more.  By the time you're done (are you ever "done???"), if you didn't allow scope creep, then what you've produced probably isn't relevant anymore! 
 
I've always lobbied for more, smaller, implementations preferring to deliver the most requested features as soon as possible to the end-user, but it's not always possible like when you're completely redesigning an interface.
 
Of course, I can't help but laugh at trying this with the Defense Contractor I worked at back in the early 80's.  To make a code change you had to:
 
1) Checkout the printed code from the facility librarian,
2) Mark the code up in red ink,
3) Make SEVEN (yes, 7!) copies to distribute for comment,
4) Attempt to incorporate all feedback with more red ink,
5) Perform steps 3 & 4 until there were no more comments,
6) Actually code & test (with any major changes going through steps 3 & 4 again),
7) Send the code to the testing department,
8) Send the code to the CMQA Tech. Lead (me) to see if it plays well with the rest of the system,
9) Send the code to the Architecture Group for actual installation and, finally,
10) Check in a printout of the final code to the facility librarian.
 
You wouldn't believe how long even a one line change took!

My shop went to staggered parallel waterfalls with merge backs.  We were doing a release every 90 days until the business cried uncle.  They couldn't train that fast.  We went to 120 days.  That was actually a pretty good pace for our industry.
 
In reality I think our biggest challenge was getting the the folks in the business, particularly product development, to finalize their plans.  They wanted 12 mos to make up their minds, then wanted a 30 day implementation.
 
 

BobF
They wanted 12 mos to make up their minds, then wanted a 30 day implementation.
 

That single sentence epitomizes my industry.