«    »

The Shocking Truth about Agile and Waterfall

There is a common perception within I.T. that Agile methods are recent innovations - the new kids on the block - and they are contrasted with the traditional waterfall approach - the old-timer that has been around for ages. This perception is propagated by events such as the widely-discussed 10-year anniversary of the agile manifesto and by the ongoing challenge of the "old guard" - either publicly or within organizations - of the effectiveness of agile versus waterfall. I recently read two articles, however, that convincingly shatter these misperceptions and lay bare the shocking truth.

While the term agile itself is indeed ten years old, the philosophy and approach of iterative and incremental development (IID) has a surprisingly rich and extensive history. The article Iterative and Incremental Development: A Brief History (PDF) by Craig Larman and Victor R. Basili published in IEEE Computer discusses how the ideas of IID actually predate the existence of software, and have been used and promoted in every decade since for over 50 years. This article also discusses a classic 1970 article by Winston Royce well-known for supposedly promoting the use of waterfall, but which actually recommended the development of an initial pilot or preliminary version prior to creating the final version intended for delivery to the client. Larman's and Basili's article also discusses the ongoing evolution of the standard used by the U.S. Department of Defense for software development. The initial standard was document-heavy, gated, single-pass waterfall, but the high rate of project failures led to first the allowance of and eventually the full adoption of IID approaches.

So a limited set of organizations (often governments due to their byzantine contracting restrictions) did experience an evolution from waterfall to agile over time, but notably they started with a misunderstood version of waterfall. The use of IID approaches has always been part of the I.T. industry.

What about the effectiveness of agile? The second article Quality metrics: Software quality attributes and their rankings is an interview with Capers Jones and Olivier Bonsignour regarding their new book The Economics of Software Quality. The authors in this book discuss the effectiveness of over 100 quality factors using research based on over 10,000 software projects. On a scale of -10 for extremely harmful to a scale of +10 for extremely valuable, Agile methods rated a 9 - highly valuable - while waterfall only rated a 1 - barely useful.

These two articles highlight the fact that agile-like methods have been in use since the start of the software field, and are on average far more effective than the waterfall approach. This leads me to conclude that there is really no defensible reason for organizations to mandate or promote the use of waterfall.

If you find this article helpful, please make a donation.

7 Comments on “The Shocking Truth about Agile and Waterfall”

  1. jgb says:

    Software quality is not a driver for software projects. Accordingly, adopting a methodology which aims to promote software quality can subvert a project.

  2. Perhaps your definition of quality differs from mine. I prefer Weinburg’s general, inclusive definition of quality as “value to a stakeholder”, which means that quality should be a driver for all software projects – every project should have a value proposition.

  3. jgb says:

    I note that you just swapped horses then as your earlier links about software quality metrics did not talk much (if at all) about stakeholder “value” (whatever that means).

    Do you have any evidence that agile methods increase stakeholder value? If so, what explains the persistence of the waterfall methodology?

  4. @jgb, I think the I.T. industry trends regarding the adoption of Agile and especially Scrum in the last several years clearly show that waterfall is on the way out, although I’m sure in some places it will persist for quite a while yet. This is not in itself evidence that agile improves delivery of value. You’d have to read Jones and Bonsignour’s book to see if their definition of quality relates to value, but they clearly have evidence showing that agile improves quality. In Caper’s past work, he has generally defined quality as lack of defects (more formally, the ratio of defect founds in production / live use divided by the defects found prior to production), and his research has shown that high quality (~95% defect removal rates) is strongly correlated with reduced project schedules, reduced total cost of ownership (software development + maintenance) as well as increased stakeholder satisfaction. So whether one uses this definition of quality, or Weinburg’s “value to a stakeholder”, either interpretation contradicts your initial comment..

  5. jgb says:

    Waterfall has been “on the way out” for forty years (see Brook’s mythical man month, or the links you have posted). There are good reasons why it is still here after 40 years of people complaining about it.

    Of all the projects I have participated in, none were *driven* by the expected quality of the code. They all had other paramount motivations.
    Often these motivations were intertwined with contract or other business obligations.

    Of course, everyone in the project would say “oh, and by the way, make sure that the code is high quality” but at no point would we change the organization of the business, or exclude the participation of some stakeholder, or change the scope of the project because it would make the code cleaner.

  6. I think we are talking about different types of quality. When I’m talking about software quality it is a lot more than just code quality in terms of good names, comments, well structured logic, etc. Software quality encompasses the functionality and non-functional characteristics such as performance, usability, and maintainability – part of which includes the understandability and modifiability of the code – or in other words code quality. So yes, if you focus overly much on code quality and sacrifice / ignore other quality attributes, you could definitely harm the project.

«    »