Mon, 13 Dec 2004
My powerbook is making truly alarming clunking noises. Gosh, could
it be the disk? I'll probably be buying a new one soon, which
can only mean that some wonderful new model will be announced
As I've mentioned before, I sometimes hang out with Andrew Pickering, head of the Sociology department at Illinois. We've talked about Agile methods, which match well his analytical framework for explaining scientific progress (as put forth in his fairly dense The Mangle of Practice). As a result, he invited me to write a chapter on Agile for a forthcoming book on "the mangle." I produced a draft in February. It was mostly a detailed retelling of a refactoring episode in manglish terms. Lots of Java.
As so often happens to me, the current draft is much different. Instead of being about the micro, it's about the macro: explaining Agile development to sociologists.
So far, so boring. But I decided to end with a topic that intrigues me. Agile software development is not "businesslike". You've got a room full of programmers yammering to each other. And let's be frank: that room is messy. There's food all over the place. Maybe toys. Tables with 3x5 cards lying on them, programmers pushing them around like game pieces. Crude, childlike graphs on the wall.
Since at least the '60's, business has been successfully domesticating programmers, and all that progress seems to have been lost. There's even a company where the dress code calls for ties, and the programmers on the Agile team have been given a waiver. That's the first step to the harder stuff. What now will prevent all that California-style New Age babbling about 'emergent design' from leading to web sites describing which crystals are best for writing PHP code? And office water coolers filled with "energy water"?
I exaggerate. A bit. But the style and many of the beliefs of Agile development do not mesh well with what's traditionally thought of as the proper business workplace and practices. So why is it that I run into business people who love their Agile teams? What is it that those teams are doing right?
Is it just that Agile projects deliver better ROI? I certainly hope they do, but that claim isn't proven. And I don't think it accounts for the distinct emotional response I've seen. And, in any case, those concerned with ROI are no more dispassionate utility maximizers than the average hairless ape, so there must be more to the success of Agile.
Not that it's always successful. We so often hear the sad tale of a new VP coming into an Agile shop and destroying the Agile teams, typically for reasons that seem (to us) raw prejudice. Perhaps the reasons why some teams sell themselves well can help those teams that don't.
Pages 8-10 of my paper give those reasons, so far as I understand them. But I could be wrong. And I've probably overlooked or incorrectly discounted some. So I'd truly appreciate reviews, which you can send to firstname.lastname@example.org. I have both a PDF of the chapter and a Word version in case you want to put comments in the text. (Sorry, RTF users: Word mangles the document when it exports it to RTF.)
I'd also appreciate comments on my description of Agility. I do use manglish jargon in that description, but in a way that I hope will still be meaningful for people who haven't read Pickering. (And I've also previously posted a description of the key terms.)
(And I have a guilty feeling that I'm being unfair to Parnas and Clements in my description of their "A rational design process: how and why to fake it." If you think I am, let me know.)