Why Continuous Delivery is so important
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.
Is Continuous Delivery in the Agile Manifesto?
The agile manifesto
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”.
What is Continuous Delivery anyway?
In the excellent book “Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation”, 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 as much as possible. (Continuous Integration is seen as a necessary precursor to Continuous Delivery, which is why you will often see the phrase CI/CD (Continuous Integration / Continuous Delivery).
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).
So why is this important?
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.
Amplifying feedback loops is in fact one of the three core principles of DevOps, and rightly so. It is crucial to any product-based organization and is a core enable of business agility.
Continuous Delivery enables quality
You can’t have quality without automated testing, continuous integration, and continuous delivery. You need to be regularly integrating and testing your code to ensure there aren’t conflicts. And to avoid the infamous “integration hell” suffered by waterfall projects, with big late code merges.
The quicker you can merge your branches, test your code and get it out there, the quicker you can reduce risk, find and fix defects and stay on top of quality issues. It’s that simple.
Automation and consistency
It’s not just about reducing your time to deliver and improving speed. Continuous Delivery requires automation, and automation results in consistency.
If your infrastructure setup, application build and install and configuration are all automated, that means less errors, less rework and more predictability. The processes will be become more simplified and streamlined. Which means less pain and risk for everyone.
Better customer experience
If you are doing continuous delivery, you are not only testing and deploying new versions faster, but fixes too. So when errors and bugs creep into production, you can get fixes built, tested and deployed in hours, not in weeks. This will reduce complaints and improve customer satisfaction, which will flow onto a better bottom line. So you should see DevOps as an investment, not a cost centre.
