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.