Scrum is a (pretty) good framework for managing requirements, how they move into and out of backlogs, and how we inspect and adapt the outcome of those requirements. But one of its weaknesses is it has very little to say about engineering practices.
One of those engineering practices is Continuous Delivery, or CD. This discipline (and some related activities, like Continuous Integration and Test Automation) is actually a very important part of Agile, although it’s not immediately clear why.
You won’t find anything about Continuous Delivery in the four values of the Agile Manifesto But if you look a little deeper, it’s in the twelve principles. It’s actually the first of those principles: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. There’s also this, in the third principle: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”.
Martin Fowler defines Continuous Delivery as “a software development discipline where you build software in such a way that the software can be released to production at any time”. How can you make sure your software is ready to be released to production at any time?
You test the hell out of it, you integrate everyone’s changes every day, and you Automate All The Things. You have to build quality in from the beginning, for every story, for every feature. If you only test for quality at the end of a cycle (or series of cycles), you’re not able to push the software out. So software can’t go out anywhere near production without being subjected to a barrage of intensive automated tests, run every day (or more frequently).
The obvious advantage of Continuous Delivery is having a stable, quality codebase, always ready to go. So you shouldn’t be getting any defects going out to customers, and if you do, you can fix them quickly.
But there’s more to it than that. Continuous Delivery is important to agile because being able to release at any time means you can close your feedback loops. If your software has good metrics built-in (and it should), you can quickly get information from your customers about what (if anything) they value in your software. But you also need to be able to respond to that information.
There’s no use collecting information daily if it takes you six months to put out a software release based on that information.