[crdoconnor]

You just said that waterfall hasn't been widespread since the 80s and then basically admitted to using it :)

These days it still happens, it's just that few people call it that unless they want to be rude.

IMHO waterfall is a natural state to revert to if you have a test deficit, technical debt and you don't trust releases that haven't gone through a round of manual testing first. The level of faith you have in your code/tests basically dictates the length of the mini-waterfall iterations.

Continuous delivery (the exact opposite of waterfall) comes equally naturally if you have no test deficit. It doesn't require some kind of paradigm shift or a special 'agile mindset', it just requires an automated regression test suite you can trust.

(this usually only happens when you write the tests first, but it's not strictly 100% necessary)

[Clubber]

Well, the definition of waterfall I grew up with was that you plan the entire project end-to-end with MS Project or something similar, including requirements gathering, delivery milestones, timelines and resource allocation. This was mainly done when building massive, in-house mainframe or AS400 apps that were expected to keep running for decades.

Waterfall, as described, carried on through the PC revolution but was falling out of favor to version scoping and planning (iterative). Iterations could be whatever you wanted. There were backlogs, usually a list of tickets in some software system like Start Team or whatever. I think Visual Source Safe had this as well. It's fairly simple, so our UI designer just build one in a week or so.

Agile and it's short sprints (2-3 weeks) fits nicely with SAAS (websites) because their distribution costs (comparatively none) doesn't lend itself to versioning (or isn't encumbered by it). I just find that the short iteration isn't ideal because the short iteration, and lack of long-vision planning doesn't allow designers to develop in a "big-picture" way.

>it just requires an automated regression test suite you can trust.

Testing doesn't really fit anywhere in the equation as a differentiation. There was automated unit testing before Agile, there just weren't any common frameworks and it usually involved custom test harnesses (usually a console/terminal app to run and log stuff).

It also requires automated deployment which can be tricky, especially when there is a single / clustered relational database involved.

In conclusion, I like the Agile methodology, I just think the short 2-3 week iterations don't fit every organization and if you can handle 1-2 month sprints, you'll have better designed software because you can see further into the future.

[crdoconnor]

>I just find that the short iteration isn't ideal because the short iteration, and lack of long-vision planning doesn't allow designers to develop in a "big-picture" way.

I don't think that kind of planning is particularly valuable. I've worked in many really unsuccessful companies that had a long term plan (which never really came to fruition) and some really successful companies which may have had a blurry long term vision about their general direction but mainly just reacted to customer input and market conditions as they saw fit.

The Linux kernel is developed in exactly this way too and it's hardly a model of an unsuccessful software project. It's not just me.

>Testing doesn't really fit anywhere in the equation as a differentiation. There was automated unit testing before Agile

Automated testing was barely used though. XP, the progenitor of agile, did emphasize it though.

It 'fits' because once you do enough of it (and you have automated releases), it just sort of stops making sense having release schedules. Every change to the code base that gets through code review and the test suite is releasable so why not release it?

>It also requires automated deployment which can be tricky

I think 2009 was the last time I worked on a system that didn't have automated deployment.

>I just think the short 2-3 week iterations don't fit every organization and if you can handle 1-2 month sprints, you'll have better designed software because you can see further into the future.

I've always aimed for iterations that are as short and tight as possible because the future - meaning how your software is really going to be used - is by far and away the least predictable thing you'll have to deal with. The most you can do is react to that quickly before veering too far down a dead end.

Hell, even when I develop software for myself I end up being surprised about how I actually end up using it.