Tom Gilb’s “evolutionary delivery,” a great improvement over its successors

Comments (9)

Print This Post Print This Post

Email This Post Email This Post


Why is it that the popularity of Agile processes appears to be in reverse order of their usefulness?

Tom Gilb’s ‘evolutionary delivery’ or Evo, dates back to the 1980′s and is more comprehensive and powerful than most of its imitators. But who uses Evo? Who is talking about it today?

There’s something odd about a software culture that is so obsessed with novelty and technological determinism that it perpetually loses the knowledge of the past in an endless pursuit of the reinvention of the wheel. The race in the 2000′s to “out-agile” each other and distance ourselves as far as possible from any crusty old notions of “software engineering” in the flight from some phantom bogeyman of the “waterfall” has resulted in the neglect of a great deal of hard-fought knowledge and wisdom from the great systems engineers of the 1960′s-1980′s. It’s our loss. We’re forgetting things that are better than what we think we know now.

There seems to be an uneasy feeling amongst parts of the Agile community that they’re running out of steam, that there aren’t enough new ideas. I think that’s true, and that there’s a simple reason for it: they bet on the wrong horse. XP is the weakest of the name-brand Agile processes, and it’s a dead end.

I don’t know if the Kanban idea will prove to be important or not, but I don’t think it is a coincidence that the strongest expression of that practice is coming from the FDD community rather than the Scrum/XP community. FDD is a better process than Scrum/XP, it appeals to a higher caliber of developers, and it never had the luxury of complacency.

But if you really want to take a step up, you should read Tom Gilb. The ideas expressed in Principles of Software Engineering Management aren’t quite fully baked into the ADD-sized nuggets that today’s developers might be used to, but make no mistake, Gilb’s thinking on requirements definition, reliability, design generation, code inspection, and project metrics are beyond most current practice. And I sort of like the quirky presentation, because it forces you to put together the pieces for yourself, which you really ought to learn to do anyway. It’s more of a “patterns and practices of evolutionary delivery” book than a how-to.

Tom and Kai Gilb also have an excellent website over at