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.
Comments
Roy Morien, 21 July 2007 at 9:16 pm
It always astonishes me the vehemence with which some people attempt to refute agile methods. I am frequently asked questions at my seminars that seem intended to show agile development methods as inadequate or unworkeable … But oddly enough, those questions are almost always just as applicable, and often more so, to the traditional plan-driven approaches, and they are asked vis-a-vis those approaches. Alternatively, the questions are utterly irrelevant anyway … such as ‘But how do agile metods overcome the problems when a client asks, late in the project, to change from a Windows environment to a Linux environment?’ See what I mean? 🙂
I also take the point about the ‘no documentation’ thing … the preference for working code delivered over detailed documentation. NOONE, to my knowledge (which I boldly suggest is quite extensive on the subject) has ever suggested that no documentation is necessary or even desireable. What I have heard is the question “Why does the IT department always want to produce volumnious documentation and reports every time they are asked to do something? Why can’t they get on with the job and fix the problem, or develop the feature?” This comes from a senior executive in a very large company (in Singapore).
But the question still hangs ominously in the air, as it has for many years, about earlier approaches such as RAD and Software Prototyping … If it is so good, why isn’t it popular?
My personal response to this is ‘Because most IT managers have no education or training in, or no real understanding of, good management practices and good project management practices. They fall back on highly procedural approaches, effectively hiding behind those to justify failure … “I can’t be blamed. We did all the right things according to the Procedures Manual”. A bit like the old saying “Noone ever got the sack for choosing IBM” (and now substitute Microsift for IBM 🙂
How about those critics of agile coming up with an explanation for the literally billions of dollars of wasted development money over the past 30 years, as practitioners and methodologists struggled relentlessly to impose more and more rigorous procedures and practices, and more and more upfront planning on developers. Can they really explain the obvious failure … in software development … of the sturdy motto ‘Plan the Work, then Work the Plan” as the foundation ethic of software project management?