The celebration of the tenth anniversary of the Agile Manifesto three years ago brought to light a curious aspect: The methodologies of Agile are so mainstream that they are largely taken for granted. Only organizations that are firmly committed to other paths do not default to the modern practices of Agility the embrace of change; the coding in short sprints; the frequent, automated testing; and short feedback loops, both from the process itself and from the customer.
The success of Agile in advancing software development so much in such a short period of time is nothing short of spectacular. Agile techniques now seem so natural and intuitively obvious that many developers cannot recall how software could have been developed other than via Agile approaches. So marches progress.
However, it's becoming clear that Agile alone is no longer sufficient to keep up with the demands of the present day. This deficiency is due in part to the fact that it was formulated to address older needs, especially the inability of projects to adapt to changing customer requirements.
Today, however, software complexity and the need for constant updates are making it difficult for leading edge organizations to keep up without moving beyond Agile and embracing continuous delivery (CD). Unlike its immediate forebear, continuous integration, the two words "continuous delivery" mean exactly what they appear to mean: a process or more accurately a project pipeline that constantly generates a deployable, tested product, even if feature-incomplete.
This pipeline attains new levels of productivity when delivering updates and patches to existing deployed products, and it is this capability in particular that is making it so appealing. Today's applications tend to have one of two front ends: a mobile UX or a Web interface. Whereas in the past, the UI was primarily crafted by developers, today designers are working side-by-side with developers to create the user experience. And they tend to be twitchy constantly making small tweaks and improvements to the software's appearance and interactions. Because it is easy to ship updates in a constantly connected world, a pipeline that can deliver small changes quickly is indeed a thing of value. Some CD organizations report pushing 10 or more updates per day. This is Agile on steroids.
CD, however, does not discard Agility. In fact, shops must have some basic Agility in place to adopt CD. The CD pipeline extends Agility in new ways, rather than replaces it. CD also moves the emphasis from the coding experience, and shifts it to the build, test, and deploy phases. CD in its original formulation looked a lot like an extension of continuous integration (CI). It added the requirement of creating a tested and deployable deliverable to the traditional CI model of build, test, get quick feedback. With this requirement, organizations using CD know at any moment that that-there binary can be deployed, because in fact its deployment has already been tested on a cohort of virtual machines. This is a powerful and empowering concept.
The definitive source of CD is the Jolt Award-winning book, Continuous Delivery, by Jez Humble and David Farley. Three years after its publication, it retains its clarity of vision and its unremitting pragmatism. Nonetheless, CD as it's practiced today adds a few customs not mentioned in the book. Notably, short standup meetings, à la Scrum; task selection and burn-down; and code reviews. Add these to core Agile practices, use the combination to drive the CD pipeline, and you have a clear picture of what post-Agile software development is today. And what it will be going forward.
It's possible to conflate this approach with DevOps, a term that means different things to different groups. For many people, DevOps is a synonym for continuous delivery, which is not really correct. Rather, DevOps is the pursuit of the synergy derived from developers working with system administrators and other operations staff. This collaboration, across a divide that has existed for decades, enables smoother roll-outs and higher-quality responses to deployment errors, unexpected mechanical problems, and (of course) software defects. While an important practice, DevOps is not, strictly speaking, a development activity and it falls somewhat after the CD cycle. That is, CD flows directly into DevOps.
What is clear is that software development during the last two to three years has changed rather significantly from what it was during the first decade of this century when Agile was a powerful solution to the limitations of earlier models. To adapt to the demands of today, however, Agile must evolve. And in my view, continuous delivery with the few additional practices I mentioned above are the definition of the new agility.