> No new technology. The project would eschew new construction techniques, designs, and train cars. Again, this mindset goes against the grain of most subway planners, who often pride themselves on delivering the latest in signaling systems, driverless trains, and so on. Melis was keenly aware that new product development is one of the riskiest things any organization can take on, including his own. He wanted none of it. He cared only for what worked and could be done fast, cheaply, safely, and at a high level of quality. He took existing, tried-and-tested products and processes and combined them in new ways.

This really hits the mark. There’s a curious dynamic in some software teams, where once they decide to add a few risks (technical, design, whatever), they become more casual about taking on additional risks. Unfortunately, risks multiply together!

Having every mega project being a full-custom multi-billion multi-decade slog is mad to me. All that work and barely any of it is reusable. There must be a better midpoint between bespoke curved glass and portakabins in a car park.

Interesting read. Of course the application to software projects and products is obvious. Agile is a word I hate, because world + dog is claiming to be agile (like it is a adjective rather than than an adverb). No surprise because the opposite of agile would be something negative, like "slow" which is of course not a great way to market yourself. So, it's a completely hollow term.

But there are some analogies. In software, decoupling things is a smart move. For example asynchronous ways of working with e.g. pull requests, allows people to continuously integrate changes and enables continuous delivery of features. Many projects and companies now do this.

The beauty is that you can also decouple the planning and processes for those features. Not a lot of companies do this (not enough I would argue) but it is very standard practice for OSS projects. E.g. Linus Torvalds doesn't give a shit how agile your team is, how your retrospective went or how many bullshit points you assigned during your bi-weekly bullshit bingo session. He'll throw your PR back at you if it isn't right. How you get it done is your problem; not his. When you get it done is your problem as well. His job is to ensure your work won't get in until it's done right. Not a lot of companies have gate keepers like that. Maybe they should. Of course maybe with a bit less of the abuse and passive aggression of course.

It's a format that stimulates experimentation as well. Somebody will do some work. And if other people like it, it gets merged and more work like it starts happening. The whole thing moves forward organically. In some projects at a ridiculous pace as well. Exactly the thing that many large companies struggle to do.

I think Google is a great example of a company struggling a lot on that front lately. But I'm sure all their teams are super agile. But I wouldn't all what they do particularly quick, smart, or effective. I think everybody, including probably many Googlers, has lost count of just how many communcation/chat/voip/video thingies they have. That's not experimenting, that's just repeating the same mistakes over and over again. We got it wrong! Again! Let's do it again. For fifteen years straight. Whatsapp comes along and eats their lunch. They copy it. And Slack comes along and eats their lunch. So they copy that and people discover they want to use Zoom instead of hangouts. So they copy that and call it Meets. Endless iterations of "maybe this will work?" .. "nope, that didn't work either" .. "This time we surely got it right!" .. "Nope, still wrong". What Google does is the opposite of Agile. It's also very expensive. And it's very common across the industry.