This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
James & Shane, On previous projects I have used waterfall, and now I use mostly Rational Unified Process. One of my more recent projects a Project Manager wanted to use Agile. I didn't see any problem from the development side of the project, as RUP and Agile are very similar, but I had concerns over the business side. I was concerned that we either didn't have enough focus from the client side or the availability of their Subject Matter Experts to be available to make a quick decision when questions arose. ie. on a near-daily basis. The SMEs were too busy with their 'day job' to be able to spend meaningful time with the development team, hence the developers would get bogged down waiting for an SME to make a decision for requirements that the developers had.
If the customer "can't keep up" to the pace of what Agile requires, should this be a warning sign for the project executives, and maybe one reason not to adopt an Agile methodology?
One of the ways agile developers "cheat" is by working closely with requirements experts (users, customers, product managers, SMEs, etc) throughout the project. This eliminates the need for up-front requirements elicitation and documentation, but replaces it with the need for continuous customer involvement.
This is remarkably effective and saves tons of time, so it's a good thing. However, if you can't get an on-site customer, you need some other way of gathering requirements. You can't just stop creating requirements documents and expect things to work out.
So yes, I would be wary of using agile development without an on-site customer. You could still use it by engaging in an up-front requirements elicitation and documentation phase, but then you'll miss out on a lot of the value agile methods bring.
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> .
One way to work around this problem is to have a "customer proxy" onsite. Typically that's a person from the development company, often a business analyst or similar, who is responsible for researching enough of the requirements upfront to be able to answer most of the questions during the iteration, and to keep in contact with the true customer.
As James indicated, that's certainly not optimal, but it might still work better than totally giving up on Agile alltogether.
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