Your thoughts on a simple waterfall vs agile comparison

I’m seeking feedback on the following comparison of agile vs waterfall(*)   The comparison is to be used as background information for a panel discussion on agile contracts, so it emphasizes those aspects which I felt were most relevant to that topic.  I’ve tried to keep it agnostic as to the exact flavour of agile to be used.

Waterfall Agile
Requirements always identified up front Requirements may be identified up front, in a concise list
Users sign off documents Users try out the software regularly
Integrate and stabilize at end Integrate and stabilize frequently
Progress is measured by milestones Progress is measured by % complete (with continuous testing)
Reduce likelihood of bad predictions through planning & signoffs Reduce impact of bad predictions though fast detection & response
Value: delivering on promises Value: openness

What are your thoughts?  I’m particularly interested in your thoughts on the second-to-last line, about the approach to “bad predictions”.  Does that make sense as it stands?  Do I need to add text explaining that I’m talking about all kinds of predictions – not only how long things will take to build, but also what should be built?

(*) Yes, I know, presenting agile and waterfall as opposites is logically flawed, since there’s no “opposite of agile“.  But we need something as background/context for the panel audience.

6 thoughts on “Your thoughts on a simple waterfall vs agile comparison

  1. The list looks good. However I don’t like comparing *agile* with *waterfall* because they are apples and oranges. Agile is a mindset or an approach to development whereas waterfall is a methodology. So we can meaningfully compare waterfall with, say, scrum or crystal. To compare Agile with something different, I’d choose a “plan centric mindset/approach” – whereas agile is (to me) a change centric approach.

    And, in agile, progress shouldn’t be measured by %age complete. Progress should be measured by “how much working software do we have in production”. IMHO until we have software in production, we have made no progress. I’m slightly more extreme than Ron Jefferies!

    http://ronjeffries.com/xprog/articles/jatagileisisnotmaybe/

  2. Hi Tim,

    Thanks. Good points about which comparisons make sense. I think the panel audience will be interested in the comparison of “how do teams typically behave” (particularly in those aspects of behaviour with obvious relevance to contracts).

    Re your second point, could you define “complete” as “in production” ;-) Doesn’t work for all teams though. I think there are valid cases for “big bang” deployment of agile products (e.g. replacing an existing system where its not practical to run both systems together with gradual transfer of functionality) and in those cases I’d use “ready for production” as my definition of done.

  3. I think that like a lot of agile proponents, you are arguing against a “Waterfall” that never existed as anything more than a sales tactic, or as a major misinterpretation of Walker Royce’s paper.

    I’m not a proponent of what is commonly described as “Waterfall”, but I’ve never seen in practiced as it is described. For example, despite working mostly in what would be called “Waterfall” processes I’ve never been on a project where all of the requirements have to be defined up front. I’ve never had users just sign off on documents (sure, to start, but they also sign off on a design architecture, wireframes, detailed page designs, actual functional prototypes if made, test versions of the software, and the final version of the software). And I’ve never been on a “Waterfall” effort where the results of one stage are 100% frozen once “complete” and can never be revisited (as is commonly attributed to “Waterfall”).

    This article is the only one I have seen that actually looks into the history of “Waterfall” and may be of interest.

    http://www.bawiki.com/wiki/concepts/sdlc-process-models/waterfall/

    Best wishes!

  4. Hi Allan,

    Thanks for your comment. Good point. I should have made it clearer that I was not primarily attempting to define any black and white distinction in what teams actually do in practice. As you say, the distinction is never black and white. I was primarily attempting to contrast the priorities, and mindsets, that I’ve observed. Particularly, in managers who sit outside/above the teams. To me, the waterfall mindset has two counter-productive effects on projects.

    1. When the team learns something, and needs to change direction as a result, the waterfall mindset encourages the team (and their managers) to see this as a failure. There’s a sense that the need to change implies a failure of the initial predictions, and that such failures reflect badly on the team. In my experience this slows down the pace of such changes (because on-one is in a hurry to admit “failure”) and increases their cost (because everyone invests more effort in formally justifying the change). In reference to your comment, I’m not saying waterfall teams don’t change things, just that they make those changes more slowly and more expensively… compared to what is optimal for the health of a project.

    2. The level of time and effort invested, in creating artifacts/documents for sign-off and reviewing them prior to signoff, is increased when the people involved have a waterfall mindset. They don’t want to be seen to make a mistake in preparing or approving the artifact. They also have the belief that changing it later will be hard, “so we better get it right now”. In my experience this results in a level of investment in artifacts that is not warranted by the true value those artifacts bring to the project.

    Thanks for the link you included in your comment. It’s more comprehensive than anything I’d previously read on the topic. Even though Royce never endorsed the concept of a strictly-linear waterfall, I can’t help but feel that many decision makers (particularly those of non-technical backgrounds) are attracted to it and seem to believe it has some validity. Admittedly, IF it actually worked, it would be convenient. But, as your comment illustrates, strict linearity never works in practice.

    Regards,

    John

  5. John,

    Thank you for responding and sorry for forgetting to come back and check for a response to my comment for so long. I think I still have two points of disagreement that I would like to raise.

    The first is in regards to your comment that “In my experience this results in a level of investment in artifacts that is not warranted by the true value those artifacts bring to the project.”

    The problem with this argument in my experience is that “Agile” seems to assume that most documents are created solely for the developers to consume. But I think one of the main purposes of documentation (especially “requirements”) is for purposes of keeping the business interests on track (preventing unnecessary scope creep), as well as for supporting post-development activities like testing and (especially) training. And while you can theoretically do agile development with contract developers, I at least have never seen that work well and detailed requirements documentation is usually critical for managing contract development efforts.

    The second is in regards to acceptance of change. As I stated above a large part (in my opinion) of the effort expended in defining detailed requirements and scope restrictions is not so much about being unwilling to change as it is about trying to restrict change to only what is necessary given the iron triangle that most project operate under. While “agile” embraces “change often, and change early” doing that well often requires deep knowledge of the business environment and goals and a skilled team that successfully build software that is easy enough to adapt. The first requires the deep involvement of business experts and senior management that are frequently not available (and without whom agile is almost completely impractical) and the second requires skilled developers who are in short supply, cost prohibitive, or both.

    I take a “do whatever works best for the situation you are in” approach to project work which means not adhering to any one approach (“waterfall”, “agile”, “other”, or parts of all of the above). But in order to do that you need to understand what situations enable what approaches to operate best, and I think there is blame (if you want to call it that) on both sides you discuss. On management for wanting to plan and control as much as possible while resisting changes from those plans; and from many agile proponents who seem blissfully unaware of the broader efforts of project work (or put another way who focus only on developers and maybe testers if they feel expansive) and what works well for those efforts (and especially on organizational realities and politics).

    I have often thought that agile works best in a continuous development approach, especially for software that is a “product” that is sold or continuously evolved. But for projects developing relatively static, one-off, or baseline software efforts I have seen the value of taking a more “Waterfall” style approach. But that’s just my opinion and I’m sure it’s one that would be strongly debated. :)

    Thank you for the interesting discussion.

Leave a Reply

Your email address will not be published. Required fields are marked *

Answer this to prove you are human *