[superuser2]

Going to have to disagree. The agile manifesto's principles [1]:

1. Customer satisfaction by early and continuous delivery of valuable software

3. Working software is delivered frequently (weeks rather than months)

4. Close, daily cooperation between business people and developers

5. Working software is the principal measure of progress

[1] https://en.wikipedia.org/wiki/Agile_software_development#The...

In fact, the only parts of it orthogonal to continuous delivery are

5. Projects are built around motivated individuals, who should be trusted

6. Face-to-face conversation is the best form of communication (co-location)

9. Continuous attention to technical excellence and good design

10. Simplicity—the art of maximizing the amount of work not done—is essential

11. Best architectures, requirements, and designs emerge from self-organizing teams

12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

And aside from (maybe) embracing remote work, I don't see those things going away anytime soon. I certainly wouldn't want to work somewhere that rejects them.

We could stand to lose the name, but probably not the ideas.

[p4wnc6]

This comment makes no sense to me.

What if the client asks you to give them a product once per year. Does Agile recommend telling them no, turning down their money, and reply, "Sorry, but Agile says I have to delivery the product continuously."

The two words "continuous delivery" mean to deliver something in such a way that the customer doesn't experience gaps between the release of improvements, upgrades, fixes, additions, or desired changes, so that they are not staccato changes at major discrete instances.

Crucially, the customer, not you, gets to decide what "staccato changes" and "major discrete instances" means to them.

If the customer says to you, "Receiving these changes any faster than once a year does not help me" then "continuous delivery" for you, in that case, does not mean the same thing as the modern buzzword ideology of continuous delivery.

Nonetheless, you could still use an Agile process in that scenario. I wouldn't recommend it though.

[superuser2]

In everything I've seen, heard, and experienced re: Agile, the core of it is "lots of small, fast waterfalls."

If a client wants to invent their own meanings for words which diverge significantly from those generally accepted in the community, I'm going to be extremely concerned about our ability to communicate effectively, and take a hard look at whether the risk/overheard of the minefield lurking in our vocabularies is worth the money.

If a customer thinks shipping once a year is "agile continuous delivery" they are wrong, just like if a car on the freeway thinks "35mph is fast enough" he is wrong. I mean, for him, sure, but not when attempting to interact with others cooperatively.

Though I'd probably humor anyone's belief of anything for enough money. And while I'd certainly prefer to work on a project that's actually doing agile, I don't doubt that under some circumstances it's more appropriate to do a traditional waterfall (and call it that).

[p4wnc6]

> In everything I've seen, heard, and experienced re: Agile, the core of it is "lots of small, fast waterfalls."

Not every problem is decomposable that way, and 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.

> If a customer thinks shipping once a year is "agile continuous delivery" they are wrong, just like if a car on the freeway thinks "35mph is fast enough" he is wrong. I mean, for him, sure, but not when attempting to interact with others cooperatively.

Not all cars are on freeways. This analogy borders on absurd.

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.

Submitting updates to the actual devices made no sense whatsoever except on an infrequent basis. The devices could not be connected to the internet for security reasons.

If you delivered software to a firm like that, and took the cocksure attitude that you seem to know better than the customer, you'd rightfully lose their business for reasons of poor software practices.

Man, the dogma of Agile is just so frustrating. It really gets me down.

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

[tootie]

Agile isn't take it or leave it. You can adopt half the principles and be better off than none. You can adopt one of them. No one will send you to jail. I've seen plenty of places run their process through sprints, but based off of a comprehensive BRD written up front.