[jayvanguard]

Has it really failed? It seems like at least some of the principles of agile are just a given now. 10-15 years ago that wasn't the case. People actually believed in waterfall.

Of course many individual teams fail at agile but those teams would probably fail no matter what approach they were using.

[wpietri]

It's a good question. But personally, I think that people would have stopped believing in waterfall approaches anyhow. Anybody sticking with 18-month release cycles today would seem like an idiot whether or not anybody had heard of Agile. And really, what a lot of supposed Agile teams are doing is really mini-waterfall: all the ceremony, shorter cycles, but just as much horseshit and self-delusion.

[collyw]

I got taught waterfall at university. Nowhere did it specify 18 month release cycles, just iterations, and going "back up the waterfall" if need be (critics of waterfall never seem to acknowledge that you can go back the way). To be honest I don't see how it actually differs from agile that much. Just less emphasis on documents up front.

[kasey_junk]

As someone old enough to have been working with waterfall when it was considered the way to write code, this comment sums up for me why Agile has not failed, despite the idiotic cottage industry sprung up in it's name.

That an emphasis on delivering software, on interactions instead of process, etc. seems normal and no different permeates the industry such that people see it as the status quo. I assure you, that is not how it used to be, and there is a huge difference other than less emphasis on documents.

[zb]

The process you're describing is the Spiral Model, not the Waterfall. The major innovation of the Spiral Model was that you acknowledged that you would need to iterate - in the Waterfall days that was considered something to be embarrassed about.

The major innovation of Agile was that you acknowledged that the various steps of the Waterfall/Spiral happen at the same time - in the Spiral days, that was considered something to be embarrassed about.

I don't doubt, by the way, that you were taught that the Spiral Model was called Waterfall. But you should be aware that this was a case of historical revisionism on the part of whomever taught you.

[collyw]

It was a while ago, but I remember spiral being taught with a big spiral diagram - looked kind of like a snail shell. And waterfall had arrows that could go back up the way if needed.

I also remember being taught that errors caught after the software had been implemented was 100% more costly to fix than errors at the design stage - I think that was the idea behind big(ger) design up front.

https://sites.google.com/site/ucscsadg12/system-domain

[wpietri]

That "errors are more costly later" notion is true for waterfall, but not for, say, Extreme Programming.

It is basically true for waterfall because the feedback loops are broken. Think cooking, for example: if I cook all my meals for a year at once and put them in the freezer, I'll have to do a lot of research and planning. Otherwise, a single mistake could lead to me throwing out up to 1000 meals.

But if I just cook every meal as I go, I can tinker quite a bit, because the cost of failure is limited to one meal. Which is no problem; if I really screw up, I just pull the frozen pizza out of the fridge.

Extreme Programming in particular can be looked at as a set of methods to flatten the cost of change curve. Then if you add the Lean Startup approach on top of that, you end up testing your core hypotheses early on, so even major shifts in business direction end up being pretty inexpensive.

[EdwardDiego]

> Has it really failed?

It works fine for us, but we have the ideal conditions for it to - business product owners who understand that their role is to provide a prioritised backlog and clarify stories in a timely manner - and nothing else. We have an organisation that accepts that the developers will drop features from a sprint to safeguard reliability and quality. We have teams that have stable core domains so that our estimations are, for the great majority, sufficiently accurate within that core domain.

Every time I see a "Agile is a scam / it's dead Jim / it's a myth" post, it usually involves into someone doing something dysfunctional and then trying to justify it with "But Agile!" in a game of Buzzword Bingo.

I went to help a local government IT department that was trying to implement Scrum to get some clarity on what the hell was going on in their dev teams, and I sat in on sprint retrospectives where all the talking was done by the 'product owner' - who was actually a rebranded business analyst who had no authority to prioritise backlogs. He wouldn't stop talking either, even when I explained to him that the retro was for the team, not him.

To that team, Scrum was a bunch of bullshit. To me, how they were doing it was obviously flawed. That said though, ultimately, that organisation has derived value from their half-assed implementation of it. It's shown them precisely who contributes in their IT team and who is cruising. They've got a few people who claim a monopoly on certain areas and jealously defend them because it makes them feel necessary and as such, safe from being laid off. Hence I had a GIS guy telling me that "You can't expect .NET developers to learn GIS!!" and an ABAP developer saying the exact same thing.

Now that organisation faces the challenge of managing the coasters out - unlike the US of A we don't have at-will employment.