More Double-Ds. This time it's AMDD.

During our three day Agile Training course with too many examples contrived to maintain audience engagement through cute caveman cartoons and engineering attempts familiar to all (house-building), one colleague questioned how suitable agile might be in model driven development.

The Agile view was presented in one instance as making use of Zeno's Paradox in reverse. The paradox says, essentially, that motion is illusory because to travel any distance there is a point half the way between start and finish (let's call this half-way) and there is also a point half the way between start and half-way (let's call this a quarter of the way) and so on. Because there are an infinite number of these half-way points it's impossible ever to get anywhere. This being the case the Agile take is that perhaps we're able to make better progress by considering how to only get half-way as opposed to considering in too much detail the end-game (or the whole journey).

If Agile's Raison (Scrum in this example) primarily is to produce some complete functionality periodically (frequently) in tight iterations then the question in the case of model development is "how much value does half an algorithm provide, if any?" If it's not possible to go to market with half a model then shooting for half-way appears only to help as a strategy for maintaining motion rather than for more frequent delivery.

Stated another way: Because the Quant team who are building complex mathematical models are unsure what the finished product will look like they almost have no choice but to work iteratively. The question is then whether their iterations include the development team and so far it looks as if they've not done so sufficiently that Agile's value here probably isn't more frequent delivery of complete vertical slices but helping to ensure that the direction traveled is more likely to be correct by facilitating conversation.

If more frequent contact between the Quant and Development team then mean fewer wasted cycles and fewer trips down blind alleys which might have resulted from more isolated efforts then it's another tick in the Adds Value column - this scenario leverages the Wisdom of Crowds. However, design by committee might just as easily be a problem instead. We'll see.

Meanwhile I'll be discovering how well Continuous Integration works on a development team of one and whether the overhead can be justified.