[crbnw00ts]

That diagram for the "waterfall" approach that they yanked from Wikipedia is a complete straw-man representation. It's nonsense.

Here is the actual, original source for the Waterfall approach, first published in 1970:

http://leadinganswers.typepad.com/leading_answers/files/orig...

If people would just bother to scroll past the first couple of pages, they will notice that the approach already includes some iteration cycles between steps.

In other words, this whole "agile vs. waterfall" debate which has wasted countless hours of human effort is based on a complete misunderstanding of what "waterfall" is in the first place. No one ever seriously proposed a model without iteration. It simply never existed in the first place!

[001sky]

"What often happens when you have these big requirements up front, is the people who are specifying the product are afraid of not getting all their ideas in, so they overscope the project. And then the development team is on the hook for delivering everything, not just the essential elements."

Isn't this the essence of the critique, though? Its not the lack of iteration, but the logic of the spec-formation.

To put this another way, you are right that it has nothing to do with the waterfall model per se. But it has everything to do with accepting the same set of behavioural assumptions. Namely, that the people who spec the model have perfect foresight regarding the spec itself.

What needs to be accepted is "incomplete spec". The problem with this is then the hold-up problem. you get held to ransom to fill in the incompletions. So what is really needed is a capability to execute this more in-house. This would prevent the re-negotiation of the economics (the hold up), because the project manager would just execute properly, directing resources (already paid for) through fiat rather by then re-negotiating vs a modified spec.

One problem with this is accountability. There would need to be more accountability, because execution of the incomplete spec will not be the same as farming responsibility for the spec out to a third party vendor.

Project managers need to get used to the idea of working intensely with a development team rather than asking for a specific thing and then walking away

[Swannie]

Here here!

It would be lovely if vendors would bid based on their experience, and be compensated for it, at a time and materials basis. The more experience and better you prove to be, the higher we're willing to pay for a better outcome, sooner.

Except that world is rife with bait and switch. And writing the code that delivers the spec is just a small part of the picture. Companies are terrible at specifying the non-functionals, delivery process expectations, operational requirements, supportability requirements, etc. When they do get it right, the costs go up, because many places quote without any concept of these things.

The sad reality is that the people who get asked to quote for these things in the software world are generally clueless about the actual domain, out of touch, and wildly wrong most of the time. And the people that specify these things are often barely any better. And lets face it, software developers are also terrible at quoting times to do a task, though that can be mitigated with a lot of experience of that task and the code base to do it on.

[MartinCron]

The conflict isn't between "agile and well understood waterfall" it's between "agile and waterfall as understood and implemented in the real world"

[jfb]

Of course, there's a fourth quadrant: "agile as understood and implemented in the real world", and that probably has as much to do with the way Agile is promoted as gargantuan waterfall catastrophes do with '80s style software engineering practice.

In my jaundiced view, none of this shit works right, and we'll be much the better off the sooner we all stop pretending that buying bags of magic beans will do anything other than make a bunch of cynical grifters rich and their naïve dupes miserable.

[dlitz]

No, I wouldn't call that a complete misunderstanding; I'd call it a minor simplifying inaccuracy.

Quoting Dr. Royce:

> Management of software is simply impossible without a very high degree of documentation.

How much documentation?

> In order to procure a 5 million dollar hardware device, I would expect that a 30 page specification would provide adequate detail to control procurement. In order to procure 5 million dollars of software I would estimate a 1500 page specification is about right in order to achieve comparable control.

5 million 1970 dollars is equivalent to about 30 million 2013 dollars, so for a $30 million project, his advice is:

1. Write a huge stack of documentation. Literally stop everything until that documentation is written.

2. Get feedback from reality and from your stakeholders exactly once.

Sure, having one opportunity to act on feedback is better than never having any, but it doesn't fundamentally change the process or the risks involved.

What the Agile folks realized is that reliable software development is an experimental process. If you only do one experiment, you're still missing that point.

[jahewson]

Yes but the waterfall paper goes out of its way to say that iteration between non-adjacent steps is a bad thing. It's still the anti-thesis to Agile.