Which Release Management aspects help explain the difference between Waterfall and Agile?

Question

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?

Answer 1

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.

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:

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:

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

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