Self-proclaimed “software economist” and “international consultant” David Longstreet posted a twelve-page paper (in PDF format) called The Agile Method and Other Fairy Tales today. I thought the paper was a joke when I started to read it, but I believe Mr. Longstreet’s over-long and poorly-written paper is serious. Software developers should read the paper, or at least skim through it. Whether you practice or believe in agile development or not it’s probably good to see some of the silly arguments and misinformation that Mr. Longstreet is pushing before your executive team hires him to speak at your company.
One scarce knows how to be serious in the Confutation of an Absurdity that shews it self at the first Sight. It does not want any great measure of Sense to see the Ridicule of this monstrous Practice; but what makes it the more astonishing, it is not the Taste of the Rabble, but of Persons of the greatest Politeness, which has established it.– Addison, Spectator No. 18 (1711)
Mr. Longstreet sets up a small army of straw men and then bravely knocks them down. Throughout the article he shows a willful ignorance of agile techniques. He trots out some familiar analogies (“I doubt if any agile proponents would like a construction company build their homes using Agile methods.”), but also comes up with some new ones. Jumping freely from musicians and composers to casino gamblers, librarians, interior designers, and courtroom juries Mr. Longstreet fills pages with analogies that seem to prove agile methodologies can’t work because other disciplines don’t use them. Lucky for orchestra conductors and professional gamblers Mr. Longstreet is not writing and lecturing about their livelihood.
Mr. Longstreet describes what anyone would recognize as bad practices, labels them as agile, and then concludes that agile development is a fraud. If agile development was really done the way Mr. Longstreet describes it I would agree with him: it would indeed be a disaster. But Mr. Longstreet is describing bad practices that agile techniques address and correct. An example: Mr. Longstreet repeatedly interprets the agile warning against generating unnecessary documentation as an absolute rule against writing anything down. From the Agile Manifesto:
Working software over comprehensive documentation…That is, while there is value in the items on the right, we value the items on the left more.
Mr. Longstreet devotes page after page tearing this straw man apart with closely-reasoned arguments like this: “The final product of a composer is formal sheet music any musician can read and play. Agile proponents believe playing by ear over site (sic) reading sheet music.” He goes on with a different analogy: “Agile proponents rely on individual’s communication and memory instead of documentation. Every thing said in the courtroom is recorded. Extremely detail (sic) documents are created by a trained court reporter.” Even a simplistic understanding of agile techniques shows that those analogies are inapt and irrelevant. As the Agile Manifesto clearly says, working software (code) is valued over documentation, but documentation may have value in addition to the code. Maybe Mr. Longstreet has never worked for or consulted with companies that require project teams to produce piles of documentation that no one ever refers to or maintains.Here’s one of the clearest examples of Mr. Longstreet’s muddled rhetoric. See if you can figure out what he means, or what this proves:
Another argument of Agile Methods is professional staff does not need to be managed as the “ole” uneducated factory worker. What about the relationship between hospital professional staff (nurses, doctors, research scientists)? Using the Agile argument, hospitals and healthcare organizations do not need management, planning or process because they are professionals and you can just rely on individual’s professionalism. The same is true for engineering, architectural firms, pharmaceutical, and law firms.
I’m not sure where in the agile literature Mr. Longstreet read that “professional staff does not need to be managed.” Mr. Longstreet doesn’t cite his sources, so who knows where he got these ideas from. A lot of what he calls agile practices are so farfetched and distorted I think he must have just made them up.
Agile techniques aren’t perfect and may not apply to every problem. Certainly agile has become a target for criticism, and it’s easy to find shops that call their broken process “agile” as window dressing. I’m sure lots of professional developers will take Mr. Longstreet to task and dissect his paper. We’re probably giving him what he wants: a lot of undeserved attention and links to his web site that he will claim supports his credentials. I hope worthier and better reasoned critiques of agile techniques will get the same amount of attention.