I would like to know how much beneficial Agile process is in terms of cost when we compare it with other development processes like RUP etc. Were you able to dig well and compare various processes to fetch some data for learners.
Well, it's not at all a scientific observation, but a number that I've seen in several experience reports from well-known companies is a time reduction of about 50%, combined with a dramatic decrease in bug count.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Productivity is very hard to study formally: first you have to have a valid definition of "productivity," which is surprisingly hard in software; next you have to somehow control for all of the variables like programmer productivity and experience; and finally you have to get a bunch of companies to agree to a long running experiment, which nobody wants to pay for.
Nobody does that, so we're stuck with little studies conducted on students (with no real experience) or industry professionals who take a day off (and solve toy problems). Net result? You can't prove anything about the effectiveness of anything.
(I'm exaggerating a bit here. Not much.)
So we're left with anecdotes, which don't prove anything either. Anecdotes like Ilja's say that agile processes are more productive and lead to higher quality than other processes. That's a common story. However, there are also stories of people who tried it and failed.
Best way to know if it will work for your team is to try it. One thing we did in our book is to identify the common characteristics of teams that struggle. We coalesced these into our "Is XP Right For Us?" section. I think that a team that changes itself to meet those conditions and then applies our advice carefully and rigorously will be faster and deliver higher quality. In many cases, I think it will be dramatically faster and higher quality. That's been my experience in applying these techniques in reality.
But I can't promise that, and you'll definitely go slower at first while you learn.
James Shore, coauthor of <a href="http://www.amazon.com/Art-Agile-Development-James-Shore/dp/0596527675" target="_blank" rel="nofollow">The Art of Agile Development</a>. Website and blog at <a href="http://www.jamesshore.com" target="_blank" rel="nofollow">http://www.jamesshore.com</A> .
A client of mine, a large multi-national, multi-continent organization has been transitioning to agile methods over the past couple of years. They did an employee survey roughly one year into the transition and found that 70% "would not want to go back to the old process", 20% had no strong opinion in either direction, and 10% would want to go back.
While it's sometimes difficult to measure things in hard numbers, just asking people for their gut feeling about which is better can already be good enough a measure.