27 August 2007

A critique of Agile as the new way

The Agile Method and Other Fairly Tales, by David Longstreet is quite a strong argument for why you are unlikely to get results from switching to an agile development methodology.

When you read the article you find the argument compelling.

If you are considering the methodology, or if you are a die hard fan this is probably an important article to read.

David is an IT professional, but is also a statistician and financial analyst. His broad industry observations are that agile isn't delivering results and that the real place to focus attention is on a quality approach to requirements management.

Read the article here.

No doubt the title should be The Agile Method and Other Fairy Tales. I also hear that Longstret is doing a talk on this topic for Atlanta SPIN soon.

==added 10th Sept==

David's offers his background in more detail;

I started this software journey as a programmer. My first software language was machine instructional cross assembler. It was basically hexadecimal machine language. I could really pump that stuff out. Early in my career I wrote Fortran code for theoretical physicists solving complex mathematical equations. Over my career I programmed in COBOL, C, C++, and Java. I actually co-authored a DOS 5.0 book that is obsolete now. Prior to becoming a consultant, I managed software developers, testers and production support teams. I have managed both technical staff and functional groups. I started out with punch cards and now I use a Mac.

For over two decades of my life I have been dedicated to the idea of improving software productivity and quality. I have traveled the globe consulting and studying software organizations that support just about every industry including banking, aerospace, retailers, animal food, telephone, consulting companies, healthcare, defense contractors, package delivery, automotive, travel, government agencies, and insurance. I have worked for organizations with only a few employees and others with billion dollar budgets.


  1. Anonymous12:05 am

    The article is poorly written and poorly edited. The "arguments" against Agile are insipid and anecdotal. I am a huge proponent of seeking structure where there is apparently none, but this paltry piece actually detracts from that objective. It should not be used to make any judgements for or against Agile methods.

  2. His business' website is here.

    He is clearly a believer in function point analysis and even offers training and consulting services in that space. To what degree function point and agile are contrary to each other… I'm not sure. At a high level agile seems to fit with function point analysis - an agile iteration could be a cluster of function points, right? Or is Agile rigorously anti analysis?

  3. Anonymous6:01 pm

    I'm not a fan of Agile methods, but David's article is highly biased and misleading in many points. I think David criticize what he believes agile methods are, not what the agile methods really are or was intended to be.

    One could easily discuss David's arguments showing counter-analogies to his comparisons. It wouldn't be very difficult to write similar article with opposite conclusions using similar level of solidity.

    My point is that every reasonable method has its place. Agile is no different here. Some ideas which became famous (I don't say invented) with agilists have been already dropped (pair programming) yet some appeared as wise and have been adopted by other methodologies (test-driven development).

    I believe in future there will be place for wide range of methodologies, including both agile and deeply formalized heavy-weight ones. None of them is universal and can be used against any software project. In other case everyone would use it.

  4. That's a fair comment.

    I'm no programmer and so no expert in software development activities. As you would know by now my approach is to let the experts do their thing with as little interferance as possible.

    I do get sceptical though when people push an ideology. I also thing the type of an organsiation will have a big influence on how well certain methodologies work.

    For example I think a less structured and planned approach will work much better in a smaller environment where expertise is valued, while in larger organisations process driven methods are much more important.

    This isn't becuase one works better than the other, but becuase of the sort of people you have working there, and that drives what is expected by the general population of the project team.

  5. Quite clearly, the author has a wrong understanding of Agile and reading his article it is obvious that he has not only not practiced it but has rushed into a judgement, that to me speaks a lot of other things as well.

    "It only tries to formalize sloppiness"; statements like these are make me question the authors credibility. To say that Agile doesn't fix the problems of requirements gathering or works only for teams of 4 or less is denying the truth that statistics reflect, which he supposedly is a master of.

    What else can I say other than, "Wake up David, get real and accept the change."

  6. I have learned it is really hard to get a good handle on Agile because they are “shape shifters.” I can quote from Agile books and even quote Agilistista’s but told, “that is not Agile.” I would encourage readers to read The original paper, "Agile Methods and Other Fairy Tales" can be read at


    I have learned from my own experiences and others the modo for Agile should be, "shut up and let me code."

    Most of the points against my paper do not deal with the paper at all, but they are attacks on me (ad hominem).

    Here are my major points about software development and most of them contradict Agile methods.

    1. Specialize along industry lines. Those organizations where the software developers are specializing and learning about their core business have the highest productivity rates. It is no longer feasible to jump across industries and be just a software developer.

    2. Customer Practices. Study thy customer. As industrial designers tell us customers often cannot articulate what they want. One of the worst ways to gather requirements is in a conference room asking someone client liaison what they want.

    3. Organize and Standardize Documentation. The biggest problem with software documentation is it is written inconsistently and not organized. Too often it is scattered about individual PC’s. I ask people if a library had the same organization for books as you have to organization your application documentation what would the library look like. It is important to use consistent terminology and verb usage in your documentation.

    4. Study other industries. There is a tremendous amount to be learned from other industries like industrial design, architecture, music and some others. Software is not unique but is like all other industries expect there is a lot of immaturity in software development.

    Most if not all Agile practices are focused on the code. By the way, when I write "study thy customer" I do not mean sit in a conference room and ask what do you want. I mean go to where they work, go study them, learn their business, so you can come up with good solutions.

    David Longstreet
    Software Economist

    1. Anonymous1:45 pm

      Hi Mr Know-it-all!

      I have been in this business longer than you, and I can tell you that...
      ...unfortunately you ar 100% right. :(

    2. Anonymous11:59 pm

      I've been doing software development for 12 years. When I read this article and even these comments I agree wholeheartedly. There are all of these people who vehemently attack this man, who has no doubt consulted and helped many firms be productive. On the other hand, "Agilists" came to my company AND COMPLETELY DESTROYED IT. Scrum Masters sit around doing nothing and preach, while POs with little experience dictate to 20 year industry veterans what they think the customer wants. This has obviously become a kind of religion and you, Freeman and company, are the inquisition. I think it is a way for people to come in to a (a priori) successful industry and steal from it.

    3. Anonymous5:38 am

      I agree David that 'Agile' (or is it 'agile') is always "shape shifting" and often vague on detail. Also there is such a wide disparity between the different flavours of agile methods that it is even confusing for Agilists (see: https://jessefewell.com/agile-vs-agile-2/).
      Also I find it amusing that many of the reasons now being listed for why agile projects fail are the exact same ones that were listed for why traditionally managed projects failed, and why a structured formal approach to managing projects became necessary in the first place. Incidentally I have a friend who is a scrum master, who often complains that "they don't do it properly".

      In my humble opinion the agile movement has been successful in political campaigning through spin (i.e. the Agile Manifesto, waterfall straw-man argument, minimum documentation, etc) in promoting their ideology, but have failed to address the real project management issues, the same ones that have always plagued projects, which are those involving project complexity and stakeholder dynamics.

      I find it amazing that people who promote the agile methodology and particularly the concept of minimum documentation (what is minimum anyway, what documents are Agilists permitted to write, and who decides the scope of what is to be written?) yet they are willing to communicate their own ideology through written documents.

      On all the traditional projects I have been involved in there has never been too much documentation, on the contrary, there is usually not enough. I often wonder on agile projects how a new team member (internal or external) coming onto an agile project integrates. Either there is a lot of hand-holding or there is more documentation produced than they care to admit to. In which case all the promised time saving benefits of agile diminish greatly.

  7. Anonymous8:22 pm

    More strawman arguments. Mr Longstreet has been told often enough about the factual errors in his article and has chosen not to correct them.

    The four points he raises in his comment are either orthogonal to any methodology or are already addressed within most Agile approaches.

    The Agile projects I've been on have had a far higher level of discipline and consistency than anything else in the organisation around them. They've also delivered more reliably and more predictably.

    Do not confuse flexibility and responsiveness with a lack of rigour.

  8. This comment has been removed by the author.

  9. Could anyone point me to an article that provides a more rigorous and respectable critique of Agile principles and the family of associated methodologies?

    I have heard and considered interesting avenues of criticism of the principles on the grounds that some underlying assumptions may be impractical or infeasible; however, I have not yet found anything along those lines published.

    My thanks to David for at least providing a forum to put forward my question - hopefully this yields better results than Google. Other than this potential value, I found the article to be a waste of my time.

  10. Here is a review of a book on the topic.

    And here is the book in question - Balancing Agility and Discipline: A Guide for the Perplexed

  11. Hey, nice site you have here! Keep up the excellent work!

    Function Point Estimation Training