The first time I became convinced that EvolutionaryDelivery would work even for larger projects went something like this:

We were introduced to a senior project manager/designer in a major financial information provider who was willing to think much more radically than normal running a 3-4 year 30-40 person redevelopment of one of the world's major real-time financial networks. He had heard Gilb personally a few weeks before and we ended up working very closely with him in rethinking the design of central databases and project plan.  

We became convinced together that there were major benefits and reduction of risk to be had by doing the project in much smaller steps than previously thought possible.  But even for us it initially seemed extremely difficult even to imagine how. It took time, prototyping and considerable expertise with the current systems to work this out.  It wasn't a one week or even a three week SpikeSolution job in this case that's for sure! That's a KeyPointToReturnTo in y2k!

Anyway, the super-manager in charge of our by now extremely friendly (technically able, tough talking and hard drinking Glaswegian) manager didn't have the time to spend to understand the incremental approach and the new plan was ditched.  

OR (the equally true version): the new plan drastically revised a plan that the super-manager ''had'' invested time in and he wanted to stay with what he knew for perfectly valid reasons of control.

OR (the more than a grain of truth version): the super-manager knew exactly how political the organisation was and how many knives were out to get him (and there were) and he couldn't afford to seem to be corrected in a big way by a couple of subordinates, even if it was for the good of the organisation at large (which it was).

Even so, it was quite clear in the months that followed that even the effort to think in an evolutionary way paid off resulting in a substantially better "WaterFall" plan.  For in the end these great polarities, ED and WaterFall, do get mungled up to some degree in every project.  

(Although it's worth saying that I also believe that the ExtremePop may be extremely significant in keeping a project in steady state ED for long stretches, longer than was possible before XP came along [see ImpactModelling on steady state]. And by their very nature the XP practices must be scalable, through probably not easily so.)

And thanks to that detailed work with our original Glaswegian friend (who went on to be promoted higher than his super-manager when I last looked!) I was convinced that radical ED surgery could indeed be provided to much larger projects.

But also that it wasn't going to be quite so easy to follow through until substantial changes in software development culture had been effected globally.  

And now it's happening! (I think)

--RichardDrake

And this story has made me realise: MostExtremeIsHeardLoudest