[hatchnyc]

It seems that with these types of changes, I mean with more and more of the workforce working on schedules that don’t overlap, it is going to become more and more important for business software to run autonomously without anyone there to babysit it, but it seems to me we have been moving in precisely the opposite direction for some time now.

Specifically “doing agile” seems to encourage this, I always see lots of supporting infrastructure being skimped on so a new feature can be delivered faster, with some hand wavy plans to fix it in some future sprint.

[RamblingCTO]

How on earth is this related to "agile" software/product development?

> I always see lots of supporting infrastructure being skimped on so a new feature can be delivered faster

That's bad management and has nothing to do with agile. Reserve time for bug fixes (or have fire fighting capabilities) and refactoring, include time for tech tickets. ALWAYS. Plan workload jointly with developers, talk to them regularly. It's that easy.

[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?

[wccrawford]

They did put "doing agile" in scare quotes to suggest it isn't really true agile development. They're claiming it, but not actually doing it right.

[RamblingCTO]

Yes, I got that! That's why I used "agile" as well. My first thought was that it might be true what they said because it might be harder to account for said work, but I think in the end it depends on the management style and the priorities. If management and the dev team don't have the right priorities, traditional or agile can't do anything about it. And the technology leader (i.e. a CTO/tech lead etc.) needs to protect devs from pressure and stress of stakeholders and users. You need to foster understanding that developing software takes time and things like proper testing, QA, security, refactoring, updating libs etc. saves you money and allows you to keep the momentum. That's the job of the CTO imho. Also: if you want to move faster, grow your team (and your structures) and see where time is wasted (we don't have a lot of meetings for devs that are mandatory besides demo, sprint planning, retro and standups and all have a max time) and don't cut corners all the time, they are coming back to bite you most of the time.

If anyone's interested, I can only recommend "Scrum and XP from the trenches"!

/e: sorry for the long text, tl;dr: have the right priorities to produce good software, agile is not the cause, your shitty management is