I needed to describe the reason that an Agile approach to software development works, and why it is not something that is isolated to the development team. I wrote up the following explanation. Maybe this will be helpful to you in explaining agile development to others.
The Road Trip Analogy
Software development can be compared to a trip, over terrain that you are unfamiliar with, and for which no map exists. It is a trip of discovery. Because it is discovery, it is impossible to predict up front exactly where you will start and stop each day, which exact route you will take, and to some extent precisely where you will end up.
If you were to program a robot to drive to an unknown destination, you would have a very difficult time planning every turn and traffic stoplight. It is very likely that the robot would go off course at some point and fail to get back on. The waterfall development approach is a bit like the robot; given a perfect map of the terrain, one can program it to go precisely to the destination through the fastest path. The problem is that you do not have a perfect map. You don’t even have a vaguely reliable map.
The point of taking an agile approach is to realize that you don’t need to predict everything up front because you have a DRIVER who can intelligently respond to the evolving situation. As you continue on the journey, you learn more about the countryside you are traveling through, and a driver can use that knowledge to pick a course that looks the most promising. If there is highway construction, the driver can find a way on the small roads. Also, if the driver hears a bad noise coming from the engine compartment, the driver can decide to stop at the next service station, which might delay the trip a bit, but also might avoid a disaster. The agile approach is not without a plan; it is not randomly across the country; it is simply that the details of the course are worked out as the journey proceeds.
Understanding Agile is not exclusively for developers. The marketing and product management people are the drivers in this analogy. They set the priorities which are the direction of the development team. Just like a driver, though, the marketing and product management people need to pay attention. This is not done just once at the beginning. There will be points of time that input is needed, and it is very important that that input is given in the correct way at the correct time. If product managers don’t understand the responsibilities, it is possible the engineering will go off in the wrong direction, and the project will miss out on the opportunity to make a product that is truly a good fit for the customers.
Thinking Matters 
The main issue I have with this approach is time to market i.e. the higher management gives you a deadline and you start development using an agile approach. in the middle you hit a blocking issue which you did not plan for in the beginning so now either you go back which will cause delays or apply patches.
in other words, in the quest to reach point Z from A. We reach point H and find out there is no way from or the road is under construction so the driver has to go back to point A.
Yes. Given the best knowledge, you plot a course from A to Z. With the waterfall approach, you get to H, get stuck, and just sit there, unable to progress, but also unable to improvise. The project fails. Eventually, you return to A. With the agile approach, when you get to H, you look around and try to improvise; You are not constrained to the original plan. Maybe you find a way. Maybe you don’t, and have to return to A. But in no case is it worse than waterfall.
This republished as an article at:
http://www.pmhut.com/agile-software-development-road-trip-analogy