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