Agile Software Development - Road Trip Analogy

February 26, 2010 | Author: PM Hut | Filed under: Agile Project Management

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/.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

3 people have left comments

How does this approach work in a corporate environment?
Most large corporations or government agencies have very restrictive approaches to project delivery.

They won’t let you jump in a car with a tank full of money and a vague note saying you may be back with dinner but don’t know if it will be fish, beef, chicken or vegetarian.

Most large organisations have teams of people that are the stakeholders who all want a say in where the project is going, and many have departments who want a say in solution design. In these sorts of organisations it would be like having 20 people telling you where to go and another team of people telling you that you were not driving in accordance with corporate policy.

I don’t think you can do an agile project without a lot of work being done within the customer organisation to make it ready to engage in an agile way.

The organisation has to give the decision making power to one person to define the requirements. They also have to allow the project team to refactor the solution when the requirements change or were incorrectly interpreted in a sprint. What project team would currently get away with reporting to the steering committee that they need to go back and refactor or redo last months sprint and can you have some more money?

John Tailby wrote on February 28, 2010 - 3:44 pm | Visit Link

There is no question that micro management is rampant, and in some cases entirely inescapable. What you mention is indeed a common corporate culture.

I wrote this piece as a way to try to explain that not all work is manageable through these means. There are different kinds of work. When building a bridge, you have a very predictable process, where each step can be mapped out in detail in advance. But there are other kinds of work that are inherently unpredictable. The exploration is a visual example of this. No doubt Ferdinand and Isabella WANTED a precise detailed day-by-day plan from Christopher Columbus, but the nature of exploration made that impossible — and they knew this.

This story is not to say that all projects should be left without any management control, but that there are some kinds of projects which simply can not be controlled this way. All too often management does NOT know this. Software development is a voyage of discovery into uncharted territory. So treatment of unusual diseases. So is coming up with a new product idea. So is writing a hit song. So is finding the criminal behind a robbery or murder. So is negotiating a treaty. These types of work are not predictable, and so can not be managed by scientific management, which assumes that such things are predictable.

Also, you should not mistake “plan” for “goal”. It is necessarily the case that those people funding a project will want to be very clear about the goal of the project. Nobody is saying they want multi-millions to spend on whatever they want. Even Columbus had a clear goal: sail to the new world. And his backers can measure success or failure against that goal. But, what this analogy argues for, is that every single step, every detailed daily plan, is NOT knowable in advance, and that it is figured out by heuristics that will be applied at the time that the work is performed.

It is also true that these needs to be constant engagement. If Columbus could have telephoned home to report position and progress, that would have been perfect. You MUST interact regularly and continuously with the customer saying “I am ‘here’, and I see X, Y, and Z, and what do you think about heading toward ‘there’”. This is not saying that you are going off wild with the money, but instead simply that the exact plan to reach the goal can not be stated in detail ahead of time. Make sense?

Here is a link to more discussion of this article:

http://kswenson.wordpress.com/2008/09/02/agile-development-road-trip-analogy/

Keith Swenson wrote on March 1, 2010 - 6:51 pm | Visit Link

Hi Keith

What you said does make sense, especially the part about management not knowing or accepting that different styles of management are needed for different styles of work.

To me your story underpins how far away from being ready for agile style development many of our corporations and government agencies are and how much they would have to reinvent themselves before they could participate in an agile style project.

I was simply trying to imagine applying what you wrote onto the project landscape of customer organisations that I know about. Trying to do agile in the existing climate would be quite rocky.

John Tailby wrote on March 3, 2010 - 9:14 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories