I’m sitting on a train from York so it seems a good time to share my train-leaving-the-station metaphor with the world. In truth, if you’ve worked with me in the last few years, or heard me speak at a conference I may already have shared it with you. But for the rest of the world, and with full embellishments....
Traditional software projects are like a train leaving the station. There is a big train sitting at Platform 9, we know its due to leave soon, but, well, you know what big long distance trains are like, it may well leave a little bit late. Still, to get a seat we need to be early so we are all rushing to the train.
Since we don’t know when the next train to this destination will go - actually, it is far from certain there will ever be another train - we want to be sure everything we need is on board. So we make sure we put everything we might need on the train. (Think of our requirements document.)
Eventually the train lumbers out of the station, overloaded. Quite possibly it leaves late because we were so busy loading the train, maybe one or two people even argued with the guard to delay departure a little bit so we could get more people and things on the train.
The train - our project - is like one of those trains you see in pictures of the Indian rail network with people crowded on and hanging out of the doors.
We all know the train is overloaded, we all know its going to arrive late, we even think it might miss the destination and arrive someplace else. But nobody wants to admit this.
(Particularly true if you have American management and British engineers because the Yanks view the Brits as being overly negative.)
At some point, beyond the half way mark it can no longer be denied that the train will arrive late. So action is taken. Things are thrown off the train to make it go faster.
By throwing things off the train we hope the train will arrive closer to the scheduled arrival time and the intended destination. However, in so much as there was rationale for putting all the things on the train there is less rationale applied to removing them. Things are thrown off the moving train because we can. (Somethings we can’t throw off because they are too connected to other things.)
In the extreme, those who put things on the train, and really know what is needed for the destination (BAs, Product Managers, etc.) never actually got on the train. Once they put the bits on the train they handed over responsibility to Project Managers to get it delivered. These guys are primarily concerned with dates and since they charged with delivering everything they don’t want to throw anything off.
Eventually, the train lumbers into the final stop - which may, or may not, be the intended destinations - with some random collection of things on board. Everyone gets off and breaths a big sigh of relief. Thank God that is over.
Then the news comes: there will be another train. We begin again.
This time though, we have all been burnt. We are going to make sure we have everything we need on the train, plus all the things we threw off the last train, and some more besides because we now understand the need for bargaining and we need levers.
Thats the traditional view. Now for the Agile view.
Instead of big trains we have a metro system - think of London tube, or better still Glasgow’s Clockwork Orange.
I leave the office at 6pm, go to the tube station and wait for a train. The sign tells me there will be one in 2 minutes, and another 2 minutes after that, and so on.
The train arrives and it is full. I have an option: Do I get on the packed, sweaty train and have an uncomfortable journey? Or do I wait 2 minutes for the next one?
I choose to wait. And while I’m waiting my phone rings. Some friends are in a pub nearby and ask if I would like a drink. I have an option: do I go and have a nice beer (valuable) with friends? Or do I value getting home more?
I go for the beer, something I would never do if there was only one train today. But knowing there will be another train, and another train, and another, means that I can go to the pub safe in the knowledge that I will still get home.
Need I say is? We need software development to be like the metro/tube system and not like the big occasional train.
Thanks for the great article. At Edvisors (www.edvisors.com) we are implementing new strategies to streamline the development process. Our example would be more in line with a bus depot. There are hundreds of buses going all the time. However, although some buses will get you where you need to go, it does not get you all the way there. Once you get to the end of the line, you have to find another bus. People were just jumping on buses so they would be moving all the time.
ReplyDeleteNow we are more organized - going less frequently but with a direct route to the destination.