Answers: <p>Not sure if there aren't any others, but these are the criteria I use:</p>
  
  <pre><code>+-------------------+-----------+-----------+
  ! Criteria          ! Agile     ! Waterfall !
  +-------------------+-----------+-----------+
  ! Release Events    ! Frequent  ! Rare      !
  ! Risk              ! Less      ! High      !
  ! Required Effort   ! Smoother  ! Peaks     !
  ! Volume of changes ! Small     ! Huge      !
  +-------------------+-----------+-----------+
  </code></pre>
  
  <p>And if you really want to experience the difference yourself as a user of some software, then think of using some software (like a Linux distribution), where you have a choice between using either of those releases:</p>
  
  <ul>
  <li><p>a "<strong><code>Rolling</code></strong>" release (==> Agile).</p></li>
  <li><p>a "<strong><code>Long Term Support</code></strong>" release (==> Waterfall).</p></li>
  </ul>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-05T07:39:34.163Z
Answers: The Linux example *might* not be very inspirational :) Personally I dislike the rolling releases because of: 1. the quality level and 2. the rather distracting changes (I prefer to focus on my work, not on the linux I'm using for my work). So I use the long(est) term ones (often way past their EOL) and only focus on a major update once every 2-3 years. Unless this is just increasing adversion to change due to aging? :)
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-03-05T07:48:48.250Z
Answers: @DanCornilescu I used this Linux example because I think it is an extreme example of "a" release mgnt aspect (ie the frequency  of releases) for both methodologied. Though "personally" I fully agree with your disliking of rolling releases, for the very same reasons you mentioned.
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-04T12:51:06.503Z
Answers: 2017-03-04T12:51:06.503Z
Answers: Pierre.Vriens
Answers: <p>IMO DevOps is culture, much like Agile (without choosing an agile methodology.) Therefore you don't &quot;do&quot; DevOps.</p>
  <p>You &quot;do&quot; a release methodology called Continuous Delivery as part of a DevOps Culture. (full disclosure, I don't think I've ever referred to CD as a release methodology before, but in my jetlagged state I think it works)</p>
  <p>If you'll buy that, then here's the definition of Continuous Delivery from one of the people who wrote the book by the same title, <a href="https://continuousdelivery.com/" rel="noreferrer">Jez Humble</a>.</p>
  <blockquote>
  <p>Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.</p>
  <p>Our goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand.</p>
  <p>We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis. We thus completely eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes.</p>
  </blockquote>
  <p>So then, you can work in an Agile methodology, having software you can demonstrate to the business, making sure you're doing proper automated testing, reacting well the change and all of the things that make it better than waterfall. All too often that <strong>doesn't</strong> mean you could actually deploy it to production.</p>
  <p>You end up with something like this:
  <a href="https://i.sstatic.net/ey7VV.png" rel="noreferrer"><img src="https://i.sstatic.net/ey7VV.png" alt="agile without cd" /></a></p>
  <p>So the software will (probably) be better when you're done then if you didn't have some sort of iterative approach, but you don't really know because real users haven't ever seen it.</p>
  <p>What you really want is something that looks more like this:</p>
  <p><a href="https://i.sstatic.net/DBXF3.png" rel="noreferrer"><img src="https://i.sstatic.net/DBXF3.png" alt="enter image description here" /></a></p>
  <p>Every iteration, something gets deployed to production. So, the software is <strong>deployed</strong>. If you decide to create downloads, open up the web server, or however you get software into the hands of users it's <strong>released</strong>.</p>
  <h2>What the heck!? I asked about DevOps! Nobody asked about Continuous Delivery!!</h2>
  <p>So what does DevOps have to do with this?</p>
  <p>It's very, very hard (approaching impossible) to truly have your software in a state where you could deploy it whenever you want unless that team is working in a DevOps culture. A culture where System Admins, DBA, SREs, Security People, Devs, QAs, etc., etc., are all part of a single team and not siloed part of an organization with handoffs.</p>
  <p><strong>Note</strong>:</p>
  <p>About part of a comment posted to this answer, which was like so:</p>
  <blockquote>
  <p>About your &quot;... software in a state where you could deploy it whenever you want ...&quot;: that reminds me about &quot;automatic pilot&quot; software (in a plane) ... My favorite question about that: &quot;<strong>Imagine an update is applied to such software ... How would you feel about doing so inflight ... While you're in onboard?</strong>&quot;.</p>
  </blockquote>
  <p>I love that question (in bold, in the above quote)! The idea of &quot;is it really ready?&quot; is something I rant about all the time - <a href="https://www.gocd.io/2016/01/17/not-done-unless-its-done/" rel="noreferrer">blog</a>. IMO it's vital that you're confident in security, performance and other too often &quot;secondary&quot; tests in order to practice CD. The features are done when they're done, but hackers are always there.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-04T17:27:30.580Z
Answers: Thank you for your interesting viewpoints/answers (and shiny images ...). I must admit I never heard about the term Release **Methodology**, though Release **Management** is what I'm pretty familiar with (for over 2 decades ...). About your "... software in a state where you could deploy it whenever you want ..." (combined with the "jetlagged"): that reminds me about "automatic pilot" software (in a plane) ... My favorite question about that: "***Imagine an update is applied to such software ... How would you feel about doing so inflight ... While you're in onboard?***".
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-04T17:40:33.507Z
Answers: I love that question! The idea of "is it really ready?" is something I rant about all the time - [blog](https://www.gocd.io/2016/01/17/not-done-unless-its-done/). IMO it's vital that you're confident in security, performance and other too often "secondary" tests in order to practice CD. The features are done when they're done, but hackers are always there.
Answers: Ken Mugrage
Answers: CC BY-SA 3.0
Answers: 2017-03-04T17:45:16.343Z
Answers: I was referring to - "Imagine an update is applied to such software ... How would you feel about doing so inflight ... While you're in onboard?"
Answers: Ken Mugrage
Answers: CC BY-SA 3.0
Answers: 2017-03-04T17:57:26.260Z
Answers: Please review my suggested edit, to integrate your interesting comment also. If you don't like it, just perform a rollback to the prior version (link is within "revisions"), and/or further improve/extend it as you like. Guess what, it seems that "inflight" some of my "permissions" got changed ... looks like I have too much rep already here to still need "approvals" for such suggested edits ... lucky us this is just some SE-software (not a suggested update to some route of a flight without prior approval from air traffic control ...). Oeps 2 (correction): it got approved at light speed ...
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-04T16:38:09.980Z
Answers: 2017-03-04T17:55:35.747Z
Answers: 2020-06-18T08:28:10.803Z
Answers: Ken Mugrage
Body: <p>When explaining DevOps to somebody, it happens that a question comes up like:</p>
  
  <blockquote>
    <p><strong>How does Release Management using the Agile methodology differ from Waterfall?</strong></p>
  </blockquote>
  
  <p>So what kind of criteria can you use to explain these differences to such audience?</p>
  
Tags: <terminology><culture><release-management><agile><waterfall>
Title: Which Release Management aspects help explain the difference between Waterfall and Agile?
UserDisplayName: Pierre.Vriens
ThreadText: # Which Release Management aspects help explain the difference between Waterfall and Agile?
  
  (Asked by: username_0 on 2017-03-04)
  
  When explaining DevOps to somebody, it happens that a question comes up like:
  
  > **How does Release Management using the Agile methodology differ from Waterfall?**
  
  So what kind of criteria can you use to explain these differences to such audience?
  
  **Tags:** terminology, culture, release-management, agile, waterfall
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-03-04. Score: 11 | Accepted answer
  
  IMO DevOps is culture, much like Agile (without choosing an agile methodology.) Therefore you don't "do" DevOps.
  
  You "do" a release methodology called Continuous Delivery as part of a DevOps Culture. (full disclosure, I don't think I've ever referred to CD as a release methodology before, but in my jetlagged state I think it works)
  
  If you'll buy that, then here's the definition of Continuous Delivery from one of the people who wrote the book by the same title, [Jez Humble](https://continuousdelivery.com/).
  
  > Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.
  >
  > Our goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand.
  >
  > We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis. We thus completely eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes.
  
  So then, you can work in an Agile methodology, having software you can demonstrate to the business, making sure you're doing proper automated testing, reacting well the change and all of the things that make it better than waterfall. All too often that **doesn't** mean you could actually deploy it to production.
  
  You end up with something like this:
  [![agile without cd](https://i.sstatic.net/ey7VV.png)](https://i.sstatic.net/ey7VV.png)
  
  So the software will (probably) be better when you're done then if you didn't have some sort of iterative approach, but you don't really know because real users haven't ever seen it.
  
  What you really want is something that looks more like this:
  
  [![enter image description here](https://i.sstatic.net/DBXF3.png)](https://i.sstatic.net/DBXF3.png)
  
  Every iteration, something gets deployed to production. So, the software is **deployed**. If you decide to create downloads, open up the web server, or however you get software into the hands of users it's **released**.
  
  ## What the heck!? I asked about DevOps! Nobody asked about Continuous Delivery!!
  
  So what does DevOps have to do with this?
  
  It's very, very hard (approaching impossible) to truly have your software in a state where you could deploy it whenever you want unless that team is working in a DevOps culture. A culture where System Admins, DBA, SREs, Security People, Devs, QAs, etc., etc., are all part of a single team and not siloed part of an organization with handoffs.
  
  **Note**:
  
  About part of a comment posted to this answer, which was like so:
  
  > About your "... software in a state where you could deploy it whenever you want ...": that reminds me about "automatic pilot" software (in a plane) ... My favorite question about that: "**Imagine an update is applied to such software ... How would you feel about doing so inflight ... While you're in onboard?**".
  
  I love that question (in bold, in the above quote)! The idea of "is it really ready?" is something I rant about all the time - [blog](https://www.gocd.io/2016/01/17/not-done-unless-its-done/). IMO it's vital that you're confident in security, performance and other too often "secondary" tests in order to practice CD. The features are done when they're done, but hackers are always there.
  
  > **Comments:**
  > **username_0**: Thank you for your interesting viewpoints/answers (and shiny images ...). I must admit I never heard about the term Release **Methodology**, though Release **Management** is what I'm pretty familiar with (for over 2 decades ...). About your "... software in a state where you could deploy it whenever you want ..." (combined with the "jetlagged"): that reminds me about "automatic pilot" software (in a plane) ... My favorite question about that: "***Imagine an update is applied to such software ... How would you feel about doing so inflight ... While you're in onboard?***".  
  > **username_2**: I love that question! The idea of "is it really ready?" is something I rant about all the time - [blog](https://www.gocd.io/2016/01/17/not-done-unless-its-done/). IMO it's vital that you're confident in security, performance and other too often "secondary" tests in order to practice CD. The features are done when they're done, but hackers are always there.  
  > **username_2**: I was referring to - "Imagine an update is applied to such software ... How would you feel about doing so inflight ... While you're in onboard?"  
  > **username_0**: Please review my suggested edit, to integrate your interesting comment also. If you don't like it, just perform a rollback to the prior version (link is within "revisions"), and/or further improve/extend it as you like. Guess what, it seems that "inflight" some of my "permissions" got changed ... looks like I have too much rep already here to still need "approvals" for such suggested edits ... lucky us this is just some SE-software (not a suggested update to some route of a flight without prior approval from air traffic control ...). Oeps 2 (correction): it got approved at light speed ...  
  
  ---
  
  ### Answer by username_0 on 2017-03-04. Score: 2
  
  Not sure if there aren't any others, but these are the criteria I use:
  
  ```
  +-------------------+-----------+-----------+
  ! Criteria          ! Agile     ! Waterfall !
  +-------------------+-----------+-----------+
  ! Release Events    ! Frequent  ! Rare      !
  ! Risk              ! Less      ! High      !
  ! Required Effort   ! Smoother  ! Peaks     !
  ! Volume of changes ! Small     ! Huge      !
  +-------------------+-----------+-----------+
  
  ```
  
  And if you really want to experience the difference yourself as a user of some software, then think of using some software (like a Linux distribution), where you have a choice between using either of those releases:
  
  * a "**`Rolling`**" release (==> Agile).
  * a "**`Long Term Support`**" release (==> Waterfall).
  
  > **Comments:**
  > **username_1**: The Linux example *might* not be very inspirational :) Personally I dislike the rolling releases because of: 1. the quality level and 2. the rather distracting changes (I prefer to focus on my work, not on the linux I'm using for my work). So I use the long(est) term ones (often way past their EOL) and only focus on a major update once every 2-3 years. Unless this is just increasing adversion to change due to aging? :)  
  > **username_0**: @username_1 I used this Linux example because I think it is an extreme example of "a" release mgnt aspect (ie the frequency  of releases) for both methodologied. Though "personally" I fully agree with your disliking of rolling releases, for the very same reasons you mentioned.  
  
  ---
  
  