Agile Software Development – Road Trip Analogy
By Keith Swenson
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.
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.
Original article can be found here.
Keith Swenson is Vice President of Research and Development at Fujitsu America Inc. and is the Chief Software Architect for the Interstage family of products. He is known for having been a pioneer in collaboration software and web services, and has helped the development of many workflow and BPM standards. He is currently the Chairman of the Technical Committee of the Workflow Management Coalition. In the past, he led development of collaboration software MS2, Netscape, Ashton Tate and Fujitsu. In 2004 he was awarded the Marvin L. Manheim Award for outstanding contributions in the field of workflow. His blog is at http://kswenson.wordpress.com/.