What does agile really bring?

Roy Osherove does a Q&A about "agile vs formal". I don't agree with that dichotomy, but I agree with his general sentiments.

Many people hear about the new agile methods and start reading up on what they mean, getting to grips with the key practices of XP, learning about sprints, scrums and all kinds of new wording. But how new are the methods and practices really?

I remember when I first heard of XP in the late nineties and a couple of devs on my team would present it to me. They gave me the classic (newbie) developer first line of XP: "In XP you dont do documentation!" "Rubbish", I thought (must admit it). A while later Becks first book came out and we got some copies, I read it and wasnt that impressed, I really should have paid more attention!

Focusing on that first concept of no documentation was and is pretty common. It is provocative and even revolutionary, many feel when they hear of it. XP also questions design, and did so during and as a reaction to the big fat methods that was all the hoopla in the nineties. "No big design" reads like an angry demonstration banner, "BDUF" and friends filled and still fill many developer newsgroups.

Yet, on closer inspection: How new are these (and other) pieces of wisdom with regard to software development?

It turns out, most are not so new - in fact, many are not new at all.

One view on the agile practices is that they are a desperate (and in my opinion successful) way to package old knowledge in undisputable clarity. XP represents a masterpiece of to the point definitions - that is what XP brings (along with some actually new things, that are quite provocative - but lets forget those for the sake of this little piece, agreed?). XP was necessary in the face of the evil trends of big fat design and specification that threatened available effectiveness (maybe even efficiencies) in application software development. We all remember the big processes sold by men from big software houses, shoved down the throats of any company that stopped to listen - regardless of whether they fit (all companies want and need to develop like... I dunno, NASA... right?).

So agile is not necessarily a trend, its more a sober reaction to the trends of the nineties trying to bring back old (forgotten?) knowledge to developers everywhere.

Refs:
(1) One of the papers in Mythical man month talks about documentation in flowcharts are pointless, and that the code should be the documentation. At the time that meant commenting the code, but even then the paper looks forward and anticipates when the code would be self-documenting. (A related (old) concept is literate programming by Knuth.)
I believe that was in 1973.

(2) Parnas talks about decomposition and design decisions and notes that development "should begin much earlier" than when these have been made. Very evolutionary, EDUF. That paper is from 1972.

I would be thrilled if anyone knows any more examples, or wants to provide more details. Technorati Profile