The train station in my home town was finished in 1913.
A train station that is 100 years old that means that it’s no longer adapted to the current needs. Meaning, they have to replace the station. Yet a nice building of 100 years old, also means that the building itself is “protected”. (Meaning they can’t destoy the look and feel of certain parts. )
These two together give some interesting dynamics. The project to replace the trainstation is a very interesting project. In this blog post, I’m going to focus on the project management part. It’s interesting because the train station will not close down while they are re-building the station. Or should I say refactoring the trainstation?
The original building they will preserve. As the building is part of the unesco world heritage (or something similar)
Yet everything else, all the train tracks, all the platforms and the tunnel below, will be replaced.
Personally I don’t believe in recreating software. Every project I know that rewrote software from scratch, was a near disaster. I once helped to coach teams that would create a software platform, to replace a few websites. (This company had a website for every country they were active in.) The decision was taken a few years before I came to replace everything. They did not want to create a link between the old website and the new one. So replacing bit-by-bit would not be possible. They considered that linking the two security systems would be too expensive. Unfortunatly when they wanted to put the new website life, a lot was not ready. And to keep their deadline, they decided (as I had predicted, 2 years before) to still link the two security systems. Only now that was quickly done, and created it’s own kind of problems.
All this to say I prefer to replace software bit by bit. Sprint after sprint, or week after week. I was on a train ride with one of the managers of that same company and we passed this train station, and he proudly said; well agile can’t work for everything, they can’t use agile to re-build this trainstation. I told him that they were actually doing very agile stuff. They had killed platform 12 and kept the whole station running while doing that.
(Ok there was a shutdown for a day or so.)
The whole rebuilding of the station will take about 20 years. That can’t be agile.Or can it? For me agile is about adapting to change. And interaction with your customers.
The replacement of the first platform (12) took much longer than expected. 22 months instead of 18 months. The engineer who explained all this said: if we would have been able to stop the station it would have been done earlier. Although I don’t know anything of building trainstations, I doubt that. Most projects take longer as expected. Especially when you are sticking to a plan that is not working. And this is where we come to the most interesting part. They did not stick to the original plan.
For platform 10 & 11, they decided to change the plan. And instead of starting to build the platform from -1 and build it up till +1. They decided to start at ground level (level 0) and build down and up almost at the same time. That way, they can keep their deadline of 18 months for level +1 (where the platforms are.) I am not sure if this also means they will make the deadline for level -1. And that is not really important, the biggest value for the trainstation is level +1 and level 0. If I remember correct, the lower levels are shops and parking spaces.
It’s important to notice that the way the station will look like, won’t change. It’s the techniques that they use to get there. (and probably some of the supporting structures, will be different.)
Like any big building that is created, they have a team of architects that are working full time. On a day to day basis this team takes decision on the infrastructure (read architecture) of the building. They don’t stick to a hug premade plan. The adapt.
If this can be done for a trainstation in use, why would that be a problem for your software?