[superuser2]

>one of the major failure modes of Agile is when you see people trying to shoehorn problems that can't be decomposed like that down into two week sprints.

Then these projects are poor fits for Agile, and the appropriate solution is to use something else.

>There are many businesses where infrequent software updates make tons of sense. For example, if you work with field deployed hardware that is not connected to a network. I worked with hardware like that in some defense situations before.

Great! Then these are appropriate places to not use Agile.

That doesn't mean you can define Agile to be "whatever is most appropriate in this situation." It's a tool in the toolbox, and sometimes it's the wrong one, but when you do reach for something else you owe your fellow craftsmen the courtesy of calling it by the correct name.

[p4wnc6]

> Great! Then these are appropriate places to not use Agile.

This is incorrect. You can use Agile for these problems, some organizations already do, and they do not violate any principle regarding continuous delivery by using Agile in these situations.

To be clear though, I feel Agile (or any fixed, one-size-fits-all prescriptive methodology for that matter) is always a bad choice, for any project.

However, trying to act like the words "continuous delivery" have a fixed, unchangeable meaning that never varies by the context of customer delivery targets is simply and unequivocally incorrect.