4 ms·

We'll cringe at the names, sure. I'll be very surprised if we actually go back to merging, integrating, testing, and releasing code once every few months/years

We'll cringe at the names, sure. I'll be very surprised if we actually go back to merging, integrating, testing, and releasing code once every few months/years instead of hours/days.

p4wnc6 10y ago
Continuous delivery is orthogonal to any particular management ideology. There's nothing inherent to Agile that relates it to continuous delivery. You could interpret the Agile principles for the sake of delivering once a year releases if you wanted. And many firms do continuous delivery for very critical products and services without using Agile nor anything even remotely like Agile.
- Robin_Message 10y ago
  Three of the four agile principles from the manifesto are: Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan All of those strongly point towards continuous delivery being part of agile. Continuous delivery is also a given in XP, one of (if not the) founding agile methodology. I think you need to dilute agile quite a lot to release once a year, although I daresay you can.
  - p4wnc6 10y ago
    See my other comment [0]. [0] https://news.ycombinator.com/item?id=12088793 https://news.ycombinator.com/item?id=12088793 It's amusing to me that the first thing people thought to do was go look up the letter of the Agile law, as if that could possibly have any bearing on this. Such a strong indication of what an empty cult Agile really is.
    - Robin_Message 10y ago
      I don't understand. The principles of agile are, to me, what agile is, not the cultish methodologies. How would you define agile? From your other comment, it seems like you're defining it as whatever is appropriate for the project. I don't disagree with that sentiment at all, but it does make the word rather pointless.
      - p4wnc6 10y ago
        > How would you define agile? It's defined by whatever practices emerge through its usage. Which ends up being a big stew of political dysfunction, time-wasting meetings, and pointless metrics. I feel it is a classic No True Scotsman fallacy to say that "any real agile implementation" does this or that, but all of these "false" Agile implementations lead to the dysfunction.
- superuser2 10y ago
  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_Agile_Manifesto 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 10y ago
    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 10y ago
      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).

We'll cringe at the names, sure. I'll be very surprised if we actually go back to merging, integrating, testing, and releasing code once every few months/years instead of hours/days.

p4wnc6 10y ago

Continuous delivery is orthogonal to any particular management ideology. There's nothing inherent to Agile that relates it to continuous delivery. You could interpret the Agile principles for the sake of delivering once a year releases if you wanted. And many firms do continuous delivery for very critical products and services without using Agile nor anything even remotely like Agile.

Robin_Message 10y ago
Three of the four agile principles from the manifesto are: Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan All of those strongly point towards continuous delivery being part of agile. Continuous delivery is also a given in XP, one of (if not the) founding agile methodology. I think you need to dilute agile quite a lot to release once a year, although I daresay you can.
- p4wnc6 10y ago
  See my other comment [0]. [0] https://news.ycombinator.com/item?id=12088793 https://news.ycombinator.com/item?id=12088793 It's amusing to me that the first thing people thought to do was go look up the letter of the Agile law, as if that could possibly have any bearing on this. Such a strong indication of what an empty cult Agile really is.
  - Robin_Message 10y ago
    I don't understand. The principles of agile are, to me, what agile is, not the cultish methodologies. How would you define agile? From your other comment, it seems like you're defining it as whatever is appropriate for the project. I don't disagree with that sentiment at all, but it does make the word rather pointless.
    - p4wnc6 10y ago
      > How would you define agile? It's defined by whatever practices emerge through its usage. Which ends up being a big stew of political dysfunction, time-wasting meetings, and pointless metrics. I feel it is a classic No True Scotsman fallacy to say that "any real agile implementation" does this or that, but all of these "false" Agile implementations lead to the dysfunction.
superuser2 10y ago
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_Agile_Manifesto 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 10y ago
  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 10y ago
    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).