[hatchnyc]

Right, nobody who has a bad experience with agile is doing it right. I am very familiar with this line of argument.

Fact remains though that back when everything was waterfall (proudly) and we shipped physical media to clients, when a bug often meant flying a support engineer out to the customer’s office, software was generally delivered more completed and vetted, and the QA group wasn’t allowed to report to the same org as developers because it was considered a conflict of interest. Now some software companies don’t even have a QA organization, we are inventing new organizational and technical structures to ensure that the developers are perpetually on call to resolve issues, and there is definitely a school of thought that says delivery of a complete product is an anti-pattern because after all every feature is just an experiment that you are testing on your users. But whatever, two different times, two different needs, two different practices, and to my point now we seem to be entering a new post-COVID era where just as waterfall doesn’t scale to a continuous delivery paradigm, “you build it, you run it” as practiced today is going to struggle with an “always on” business which has no “after hours” due to more flexible working schedules.

Are there companies today that run true 24/7? Sure, plenty, but they tend to be larger and have the staff to cover this. A great deal of business software today is still very fragile operationally and has deployment, management, and maintenance tied to the 9-5, M-F business schedule. I think it is going to have to evolve.

[RamblingCTO]

> Now some software companies don’t even have a QA organization, we are inventing new organizational and technical structures to ensure that the developers are perpetually on call to resolve issues, and there is definitely a school of thought that says delivery of a complete product is an anti-pattern because after all every feature is just an experiment that you are testing on your users.

That's bad management again imho, not tied to agile. I hope you're not working like that! We are a small startup and have a ratio of 2 QA per 7 developers. And QA is kind of outside the scrum process (with more QA resources I could have some integrated and working on new features directly, that would be nice, but you know, money and stuff). We actually run automated end-to-end tests via selenium via CI on every new docker image release on a production-like environment. Plus manual QA.

My point wasn't that "agile" wasn't done right, but that management is shit and it wouldn't even make a difference if you used waterfall or agile in this situation.

Also, > to ensure that the developers are perpetually on call to resolve issues

That's a good way to get rid of your developers lol.

You're points about "always on" business are interesting, but I don't experience it like that. Maybe depends on the country/sector?