The Train has Left the Station

Many have heard this when discussing software enhancements, using the analogy that the software release is a train, and it is too late to get the feature into the product (even though the product is not yet released to the public).

I have put some thought into this analogy recently, and it is very interesting how far you can take the analogy and have it still hold up. It actually makes for a great way to help keep an agile process (or any process, really) on track (pun intended...).

Here is how it works:

First, we need to understand our terminology:

• The Train is the Product Release (ours arrive at their destination every 5 weeks)
• The Train Station is where Passengers board the train
• The Destination is a public release (at some point in the future)
• The Passengers are the Enhancements, or new features, for that product
• The Luggage is the design documents, screen shots, etc that describe the feature (i.e., their clothing, makeup, etc)
  
• The Ticket Counter operators are the Product Managers, Interactive Designers and QA people (in a test-first methodology, you have test cases before development starts)
• The Ticket Takers are the Developers (they put the passengers on the train)
• And, this train has a "freight" car, which is the bugs that are being fixed for this release (you can't leave them out, as they take development and testing resources as well as the features)
  

Now, there are plenty of "potential passengers" who are no where near the train station. These are enhancements that are simply a gleam in someone's eye, and may or may not actually make it onto the train at some point. Some may live very close to the station, and may be on "stand-by".

The passengers in the train station are those features that are high on the priority list. Many of them are standing at the ticket counter, awaiting their ticket. In order to obtain a ticket, they need to have their luggage with them (if they have any). Applying the test-first process, this means that they have to have their test case, screen shot, etc with them (i.e., documentation regarding the feature has been created and is "attached" to to it in whatever form you use to track enhancements).

Once they obtain a ticket, they are allowed to board the train. The train that is in the station being boarded is the next-in-line public release, which is beyond the scope of the train that has "left the station" - that is, the development team is already working on getting a train to its destination, and it is too late to add more features to it. The features being "boarded" now are for the following train, which has not yet started development.

Some ticket takers have been known to allow a passenger onto the train without a ticket. This would be a developer who sees a waiting "passenger", and decides to proceed without waiting for the passenger to be ticketed - this is how some features "sneak" into a release without getting designed first. While this is not always a good thing, it is better to spend the time on a feature that is a high-priority than some passenger who is not even close to the station yet...and some passengers can travel much lighter than others, and don't need as much design.

Note that if the freight car is too heavy, it may require removing a passenger car from this train - that is, if engineering is too busy fixing bugs for this release, some feature enhancements may have to wait for the next train.

Well, you get the idea. As I said, the analogy holds up fairly well, as long as you are willing to stretch the imagination just a little bit. You can even have some fun with it - set up queries in your bug/enhancement database to match these concepts (potential passengers, passengers at the ticket counter, boarded passengers, and passengers already traveling), and post them on your intranet - it is a good, light-hearted way to keep everyone informed and on the same page. And, it keeps your trains moving, and helps to prevent stow-aways from derailing a release...