I've been giving this quite a bit of thought over the last few months as I've read more about agile development and trying to understand how some of its benefits could be applied to my job as a Mech Engineer.

I work, primarily, designing coal wagons for trains. Each wagon costs ~$200k and we have well north of 5000 almost-identical wagons of this sort in the fleet. As such, the up-front cost of design is incredible compared to developing software and changes to the design are incredibly inflexible compared to software.

If I want to modify something insignificant (even as small as bolting on something pre-fabricated), it takes at least 12 months to cover the entire fleet as the most minor scheduled maintenance cycle. Major modification work (e.g.: actually modifying the structure) becomes a $hundred-million, ~5 year affair.

A/B testing is a completely foreign concept not only because change is unwieldy but because individual wagons will not experience the exact same conditions (even if they're in the same train!). It's almost always impossible to control everything and vary only 1 condition.

In this and many other mechanical industries, you don't work 'agile'. You invest a lot of time and money up-front to get things right because the change cost is incredible. The whole thing is referred to as FEED [1] - Front-End Engineering Design.

The best analogy software guys might know is if you deploy a whole heap of disconnected embedded systems to difficult-to-reach locations. In this case, agile doesn't work. The quintessential example would be software on space systems e.g.: satellites, the shuttle, etc.

If you can get away with it, agile development brings a whole load of benefits. You can quickly iterate and test. You don't have to nail down your client with a specification then try to appease them when you inevitably tell them that it's too late to change stuff. Software is a great benefactor of this because duplication is literally a case of cloning software and spinning up another virtual machine. It's trivial to create a million identical copies where you can vary one specific factor and observe results over a statistically significant sample.

I don't think it's a case of agile being 'in vogue' rather than it being the better tool for the job of software development. Nor do I think it's a case of being 'bad' at waterfall approaches but rather spoiled by the luxuries that agile can bring - you don't truly commit to nailing down a scope exactly and sticking to it when it is common knowledge that change is so easy to execute.

Other industries can't afford these luxuries. Change costs heaps of time and money so you spend a great deal of pain on getting your client mentally prepared that once they press the go button, they are locked in. You have to really throw everything you have at getting it right the first time. One Kelly Johnson, of the same Skunk Works as the parent article, summed some of it up in his 14 rules of management [2] - well worth a read and note #10 in particular.

Unfortunately, I haven't yet really realised any great insights into how FEED-style design could benefit from lessons learned out of agile-style approaches. Maybe it's because I've not yet worked under the latter. It seems to me though that, perhaps as a result of how FEED works, it's a system that tends to attract oldschool, tried-and-true approaches rather than anything radical or new and that to me suggests that it's ripe for disruption and improvement.

[1] http://en.wikipedia.org/wiki/Front-end_loading

[2] http://en.wikipedia.org/wiki/Kelly_Johnson_%28engineer%29#Ke...